Spinnaker – Amazon Web Services

Docs: Amazon EC2

Mon, 01 Jan 0001 00:00:00 +0000

An older doc is available that has some information around installing spinnaker but is no longer recommended nor supported AWS tutorial: Continuous Delivery using Spinnaker on Amazon EKS .

The AWS EC2 Provider allows you to deploy AWS EC2 resources with Spinnaker. The most common use case is the creation of AMIs and deploying the AMI’s to new autoscaling groups and then deleting the previous autoscaling groups.

Refer to the AWS Cloud Provider Overview to understand how AWS IAM must be set up with the Spinnaker AWS EC2 provider. It’s recommended to use node/pod roles to access AWS services and resources securely.

Creating the IAM structure with the AWS IAM Console

In AWS , an Account maps to a credential able to authenticate against a given AWS account . For the example below, the AWS Account spinnaker assumes the spinnakerManaged role in the AWS accounts develop and staging. The account spinnaker is where Spinnaker runs.

Before you start, create a table that maps the account names to account IDs for your desired set up. An example table is shown:

Name	Account Id
spinnaker	100000000001
develop	200000000002
staging	300000000003

These examples are used in the subsequent sections.

For IAM, you can either create IAM users or roles but it is recommended to use IAM roles. To use a user, you’ll do the same as roles but use access key and secrets to set the configuration information. This option is not recommended but many users start with an IAM User for simplicity.

Navigate to the AWS IAM console.

Switch to the spinnaker AWS Account.

Add a user and name it spinnaker.

Check the “Programmatic access” checkbox.

Create the user.

Save the “Access key ID” and “Secret access key” as you’ll set these in spinnaker

This can be used for target accounts as well as spinnaker itself. The rest of this documentation will assume you are using roles going forward. For settings on the aws account to use a USER, see the configuration properties file NOTE: This is for spinnaker itself, NOT target accounts. For more information, please join slack and ask questions in the #sig-aws channel

Create Roles

Setup two roles:

Spinnaker role that spinnaker will operate as it’s primary role. This role should have the necessary permissions to assume into other roles as well as any additional access LIKE IAM Permissions for S3 for canary storage or similar.
spinnakerManaged role. This is the role the Spinnaker role will assume in the develop and staging target AWS accounts using AWS trust relationships to do deployments.

Role for spinnaker

Navigate to the AWS IAM console.
Switch to the AWS Account where spinnaker runs.
Go to Roles > Create Role.
Select EC2 for the trust relationship. Spinnaker will assume this role and it’s assumed that spinnaker is running on the nodes where this role will be assigned. For more advanced configurations, see AWS docs on pod identity or IRSA configurations.

AWS Policy for Spinnaker

The AWS IAM policy gives permissions to the spinnaker role to assume the spinnakerManaged roles in target accounts (develop and staging). Additional permissions LIKE S3 will be necessary depending upon features enabled in spinnaker

Select the AWS account where Spinnaker runs.
Access AWS IAM console.

Add a policy using the following JSON:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeAvailabilityZones",
                "ec2:DescribeRegions"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Action": "sts:AssumeRole",
            "Resource": ["*"],
            "Effect": "Allow"
        }
    ]
}

Note that this policy has access to EC2 for listing regions for startup. Additionally, the AssumeRole allows spinnaker to assume into ANY target account. This can enable a dynamic account setup.

Give the policy a descriptive name, such as SpinnakerPermissions.
Create the policy.

Additional Permissions

Additional permissions for bake operations are needed if you plan to have spinnaker create AMIs. These can be assigned to rosco via service accounts and IRSA to reduce permissions scope.

{% collapsible “Packer Permissions Example” %}

Example policy for packer

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PackerEC2InstanceLifecycle",
      "Effect": "Allow",
      "Action": [
        "ec2:RunInstances",
        "ec2:TerminateInstances",
        "ec2:StopInstances",
        "ec2:StartInstances",
        "ec2:CreateTags",
        "ec2:DeleteTags",
        "ec2:DescribeInstances",
        "ec2:DescribeImages",
        "ec2:DescribeAmiAttribute",
        "ec2:DescribeRegions",
        "ec2:DescribeSubnets",
        "ec2:DescribeVpcs",
        "ec2:DescribeKeyPairs",
        "ec2:CreateKeyPair",
        "ec2:DeleteKeyPair"
      ],
      "Resource": "*"
    },
    {
      "Sid": "PackerImageManagement",
      "Effect": "Allow",
      "Action": [
        "ec2:CreateImage",
        "ec2:DeregisterImage",
        "ec2:ModifyImageAttribute",
        "ec2:ResetImageAttribute"
      ],
      "Resource": "*"
    },
    {
      "Sid": "PackerVolumeManagement",
      "Effect": "Allow",
      "Action": [
        "ec2:CreateVolume",
        "ec2:DeleteVolume",
        "ec2:DescribeVolumes",
        "ec2:AttachVolume",
        "ec2:DetachVolume"
      ],
      "Resource": "*"
    },
    {
      "Sid": "PackerSnapshotManagement",
      "Effect": "Allow",
      "Action": [
        "ec2:CreateSnapshot",
        "ec2:DeleteSnapshot",
        "ec2:DescribeSnapshots"
      ],
      "Resource": "*"
    },
    {
      "Sid": "PackerSecurityGroupManagement",
      "Effect": "Allow",
      "Action": [
        "ec2:CreateSecurityGroup",
        "ec2:DeleteSecurityGroup",
        "ec2:DescribeSecurityGroups",
        "ec2:AuthorizeSecurityGroupIngress",
        "ec2:RevokeSecurityGroupIngress"
      ],
      "Resource": "*"
    }
  ]
}

{% endcollapsible %}

Create Managed Roles in each target AWS Account

Next, create the spinnakerManaged role in the develop ID=200000000002 and staging ID=300000000003 accounts.

Navigate to the AWS IAM console.
Switch to the AWS Account you want to create the role for.
Go to Roles > Create Role.
Select “Custom Trust Policy”. Use the following JSON:

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
           "AWS": [
             "arn:aws:iam::100000000001:role/spinnaker"
           ]
         },
         "Action": "sts:AssumeRole"
       }
     ]
   }

Click next to add permissions. For permissions, search for “PowerUserAccess” and select this policy. This gives the role permission to access MOST aws resources. More scoped permissions CAN be set as needed.
Add tags that will help you identify this role.
Enter a role name: spinnakerManaged.
Create the role.

Select the role and add an inline policy allow spinnaker to pass roles and get cert information. This isn’t by default included in the PowerUserAccess permission.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "iam:ListServerCertificates",
                "iam:PassRole"
            ],
            "Resource": [
                "*"
            ],
            "Effect": "Allow"
        }
    ]
}

Name the policy “PassRole-and-Certificates”.
Create the policy.

Repeat these steps for the second AWS account. In this example, that is the staging environment.

Spinnaker Configuration

After the AWS IAM structure has been set up, the next step is to add the accoounts to spinnaker to allow it to deploy to these accounts.

Enable the AWS provider

In the clouddriver config example here add a section;

aws:
  enabled: true
  primaryAccount: develop
  accounts:
  - name: develop
    environment: something
    defaultKeyPair: keypairs
    permissions:
      READ: 
      - groupone
      WRITE:
      - groupone
    assumeRole: role/spinnakerManaged
    accountId: 200000000002
    regions:
    - us-east-1
    - us-west-2

Setup orca

You’ll also need to set a default bake account in the orca config file that has to match one of the above accounts:

default:
  bake:
    account: develop

For information about the available parameters, see the source code on an assumed role account

Additional feature config for AWS provider

We recommend enabling AWS Launch Templates for your autoscaling groups to get the latest EC2 features. You can learn how to enable this within the Launch Template Setup Guide .

Next steps

Optionally, you can enable other AWS Providers:

Otherwise you are ready to choose an environment in which to install Spinnaker.

Docs: Amazon ECS

Mon, 01 Jan 0001 00:00:00 +0000

In the Amazon ECS cloud provider, an Account maps to a Spinnaker AWS account, which itself is able to authenticate against a given AWS account .

Prerequisites

Amazon ECS cluster

You need to create an Amazon ECS cluster . If using the ‘EC2’ launch type, this cluster must have enough EC2 instance capacity in it to deploy your containers. If using the ‘Fargate’ launch type, you don’t need to add any capacity to this cluster.

Networking

If using the ‘awsvpc’ networking mode (required for the ‘Fargate’ launch type), you need a VPC with at least one subnet group and security group visible in Spinnaker.

If using other networking modes like ‘bridge’, you don’t need to setup any further networking. The cluster’s networking configuration will be passed from your cluster’s EC2 instances to your containers.

Service-Linked IAM Roles

The Amazon ECS cloud provider requires service-linked roles for Amazon ECS and Application Auto Scaling. To create the required service-linked roles, run the following commands.

aws iam create-service-linked-role --aws-service-name ecs.amazonaws.com
aws iam create-service-linked-role --aws-service-name ecs.application-autoscaling.amazonaws.com

See the Amazon ECS service-linked role documentation and the Application Auto Scaling service-linked role documentation for information on the permissions in these roles.

Task Execution IAM Role

Some Amazon ECS services require a task execution IAM role , such as services running on AWS Fargate. If you are using task definition artifacts in your Spinnaker pipeline, the task execution role can be specified in the artifact’s task definition file.

If you are not using a task definition artifact (or if the artifact’s task definition file does not specify a task execution role) for a server group running on Fargate, the Amazon ECS cloud provider will fallback to using the cloud provider account’s assumed IAM role as the task execution role. In that situation, the IAM role for the cloud provider account associated with the Amazon ECS server group must allow Amazon ECS to assume the role in its trust policy.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": [
          "ecs-tasks.amazonaws.com"
        ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

For information on how to configure the IAM role associated with the cloud provider account, see the AWS provider documentation . For information on how to modify IAM roles in the AWS console, see the AWS documentation .

Optional: IAM Roles for Tasks

You can create IAM roles for tasks and associate them to your Amazon ECS provider server group in Spinnaker, so that your application’s containers have access to IAM role credentials. The task role must allow Amazon ECS to assume the role in its trust policy.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "ecs-tasks.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

For information on how to modify IAM roles in the AWS console, see the AWS documentation .

Optional: Service Auto Scaling

You can configure your Amazon ECS services to use Service Auto Scaling . Service Auto Scaling policies adjust your Amazon ECS service’s desired count up or down in response to CloudWatch alarms (e.g. tracking the CPU utilization of an Amazon ECS service, or tracking a custom metric) or on a schedule (e.g. scale up on Monday, scale down on Friday).

Configure scaling policies on your Amazon ECS services using the Application Auto Scaling APIs or in the Amazon ECS console, outside of Spinnaker. When deploying a new server group in Spinnaker, you can copy these scaling policies from the previous service group by enabling the “copy the previous server group’s autoscaling policies” option.

Spinnaker configuration

Enable ECS Provider

Make sure that the AWS Provider is already enabled. Proceed to enable the ECS provider in clouddriver (example)

aws:
  enabled: true
  accounts:
    - name: aws-account-name
      accountId: "123456789012"
      regions:
        - name: us-east-1
  defaultAssumeRole: role/SpinnakerManaged

ecs:
  enabled: true
  accounts:
    - name: ecs-account-name
      awsAccount: aws-account-name

Next steps

Optionally, you can set up another cloud provider , but otherwise you’re ready to choose an environment in which to install Spinnaker.

Docs: Amazon Web Services Concepts

Mon, 01 Jan 0001 00:00:00 +0000

Concepts

There are two types of Accounts in the Spinnaker AWS provider:

AWS Managing account
AWS Managed account(s).

Note The AWS IAM structure must be set up prior to adding the accounts to spinnaker.

From the AWS perspective, AWS Managing account assumes control of the AWS Managed account(s) through the use of AWS IAM Roles. By assuming a role across AWS Accounts, Spinnaker can control AWS resources from multiple AWS Managed accounts.

Refer to AWS IAM Providing Access to multiple AWS Accounts for AWS technical details.

AWS Managing account. There is always exactly one managing account. This account is what Spinnaker authenticates as and, if necessary, uses to assumes roles in the managed account(s). It’s identified via the aws.primaryAccount property in the clouddriver configuration files.
AWS Managed. Every AWS account that you want to modify resources in is a managed account. Managed accounts require AWS IAM policies and a trust relationship to grant AssumeRole access to the managed account(s).

The AWS Managing account assumes the roles of the AWS Managed account(s).

Example: AWS Managing account spinnakermanaging can assume the Managed role in the accounts accountdev, accountstaging, accountprod and deploy a baked AMI in the pipeline.

There are several ways to configure the Amazon Web Services (AWS) Cloud Provider. Choose one or more based on your requirements:

Amazon Elastic Compute Cloud (EC2) - - Use this option, if you want to manage EC2 Instances via Spinnaker
Amazon Elastic Container Service (ECS) - Use this option, if you want to manage containers in Amazon ECS
Amazon Elastic Kubernetes Service (EKS) - Use this option, if you want to manage containers in Amazon EKS . This option uses Kubernetes (manifest based) Clouddriver