Kubernetes-native declarative infrastructure for AWS.

What is the Cluster API Provider AWS

The Cluster API brings declarative, Kubernetes-style APIs to cluster creation, configuration and management.

The API itself is shared across multiple cloud providers allowing for true AWS hybrid deployments of Kubernetes. It is built atop the lessons learned from previous cluster managers such as kops and kubicorn.

Documentation

Please see our book for in-depth documentation.

Launching a Kubernetes cluster on AWS

Check out the Cluster API Quick Start for launching a cluster on AWS.

Features

• Native Kubernetes manifests and API
• Manages the bootstrapping of VPCs, gateways, security groups and instances.
• Choice of Linux distribution between Amazon Linux 2, CentOS 7 and Ubuntu 18.04, using pre-baked AMIs.
• Deploys Kubernetes control planes into private subnets with a separate bastion server.
• Doesn’t use SSH for bootstrapping nodes.
• Installs only the minimal components to bootstrap a control plane and workers.
• Supports control planes on EC2 instances.
• Experimental EKS support

Compatibility with Cluster API and Kubernetes Versions

This provider’s versions are compatible with the following versions of Cluster API:

This provider’s versions are able to install and manage the following versions of Kubernetes:

* Not management clusters

Each version of Cluster API for AWS will attempt to support two Kubernetes versions; e.g., Cluster API for AWS v0.3 supports Kubernetes 1.16, 1.17, 1.18 etc.

NOTE: As the versioning for this project is tied to the versioning of Cluster API, future modifications to this policy may be made to more closely align with other providers in the Cluster API ecosystem.

Kubernetes versions with published AMIs

See amis for the list of most recently published AMIs.

clusterawsadm

clusterawsadm CLI tool provides bootstrapping, AMI, EKS, and controller related helpers.

clusterawsadm binaries are released with each release, can be found under assets section.

Getting involved and contributing

Are you interested in contributing to cluster-api-provider-aws? We, the maintainers and community, would love your suggestions, contributions, and help! Also, the maintainers can be contacted at any time to learn more about how to get involved.

In the interest of getting more new people involved we tag issues with good first issue. These are typically issues that have smaller scope but are good ways to start to get acquainted with the codebase.

We also encourage ALL active community participants to act as if they are maintainers, even if you don’t have “official” write permissions. This is a community effort, we are here to serve the Kubernetes community. If you have an active interest and you want to get involved, you have real power! Don’t assume that the only people who can get things done around here are the “maintainers”.

We also would love to add more “official” maintainers, so show us what you can do!

This repository uses the Kubernetes bots. See a full list of the commands here.

Build the images locally

If you want to just build the CAPA containers locally, run

	REGISTRY=docker.io/my-reg make docker-build

Tilt-based development environment

See development section for details

Implementer office hours

Maintainers hold office hours every two weeks, with sessions open to all developers working on this project.

Office hours are hosted on a zoom video chat every other Monday at 10:00 (Pacific) / 13:00 (Eastern) / 18:00 (Europe/London), and are published on the Kubernetes community meetings calendar.

Other ways to communicate with the contributors

Please check in with us in the #cluster-api-aws channel on Slack.

Github issues

Bugs

If you think you have found a bug please follow the instructions below.

• Please spend a small amount of time giving due diligence to the issue tracker. Your issue might be a duplicate.
• Get the logs from the cluster controllers. Please paste this into your issue.
• Open a new issue.
• Remember that users might be searching for your issue in the future, so please give it a meaningful title to help others.
• Feel free to reach out to the cluster-api community on the kubernetes slack.

Tracking new features

We also use the issue tracker to track features. If you have an idea for a feature, or think you can help kops become even more awesome follow the steps below.

• Open a new issue.
• Remember that users might be searching for your issue in the future, so please give it a meaningful title to help others.
• Clearly define the use case, using concrete examples. EG: I type this and cluster-api-provider-aws does that.
• Some of our larger features will require some design. If you would like to include a technical design for your feature please include it in the issue.
• After the new feature is well understood, and the design agreed upon, we can start coding the feature. We would love for you to code it. So please open up a WIP (work in progress) pull request, and happy coding.

“Amazon Web Services, AWS, and the “Powered by AWS” logo materials are trademarks of Amazon.com, Inc. or its affiliates in the United States and/or other countries.”

Getting Started

Quick Start

In this tutorial we’ll cover the basics of how to use Cluster API to create one or more Kubernetes clusters.

Installation

Common Prerequisites

• Install and setup kubectl in your local environment
• Install Kind and Docker

Install and/or configure a Kubernetes cluster

Cluster API requires an existing Kubernetes cluster accessible via kubectl. During the installation process the Kubernetes cluster will be transformed into a management cluster by installing the Cluster API provider components, so it is recommended to keep it separated from any application workload.

It is a common practice to create a temporary, local bootstrap cluster which is then used to provision a target management cluster on the selected infrastructure provider.

Choose one of the options below:

1. Existing Management Cluster

   For production use-cases a “real” Kubernetes cluster should be used with appropriate backup and DR policies and procedures in place. The Kubernetes cluster must be at least v1.19.1.

   export KUBECONFIG=<...>
   

OR

2. Kind

   kind can be used for creating a local Kubernetes cluster for development environments or for the creation of a temporary bootstrap cluster used to provision a target management cluster on the selected infrastructure provider.

   The installation procedure depends on the version of kind; if you are planning to use the Docker infrastructure provider, please follow the additional instructions in the dedicated tab:

   DefaultDocker

   Create the kind cluster:

   kind create cluster
   

   Test to ensure the local kind cluster is ready:

   kubectl cluster-info
   

   Run the following command to create a kind config file for allowing the Docker provider to access Docker on the host:

   cat > kind-cluster-with-extramounts.yaml <<EOF
   kind: Cluster
   apiVersion: kind.x-k8s.io/v1alpha4
   nodes:
   - role: control-plane
     extraMounts:
       - hostPath: /var/run/docker.sock
         containerPath: /var/run/docker.sock
   EOF
   

   Then follow the instruction for your kind version using kind create cluster --config kind-cluster-with-extramounts.yaml to create the management cluster using the above file.

Install clusterctl

The clusterctl CLI tool handles the lifecycle of a Cluster API management cluster.

curl -L https://github.com/kubernetes-sigs/cluster-api/releases/download/v1.1.3/clusterctl-linux-amd64 -o clusterctl

chmod +x ./clusterctl

sudo mv ./clusterctl /usr/local/bin/clusterctl

clusterctl version

curl -L https://github.com/kubernetes-sigs/cluster-api/releases/download/v1.1.3/clusterctl-darwin-amd64 -o clusterctl

curl -L https://github.com/kubernetes-sigs/cluster-api/releases/download/v1.1.3/clusterctl-darwin-arm64 -o clusterctl

chmod +x ./clusterctl

sudo mv ./clusterctl /usr/local/bin/clusterctl

clusterctl version

brew install clusterctl

clusterctl version

curl https://github.com/kubernetes-sigs/cluster-api/releases/download/v1.1.3/clusterctl-windows-amd64.exe -o clusterctl.exe

clusterctl version

Initialize the management cluster

Now that we’ve got clusterctl installed and all the prerequisites in place, let’s transform the Kubernetes cluster into a management cluster by using clusterctl init.

The command accepts as input a list of providers to install; when executed for the first time, clusterctl init automatically adds to the list the cluster-api core provider, and if unspecified, it also adds the kubeadm bootstrap and kubeadm control-plane providers.

Enabling Feature Gates

Feature gates can be enabled by exporting environment variables before executing clusterctl init. For example, the ClusterTopology feature, which is required to enable support for managed topologies and ClusterClass, can be enabled via:

export CLUSTER_TOPOLOGY=true

Additional documentation about experimental features can be found in Experimental Features.

Initialization for common providers

Depending on the infrastructure provider you are planning to use, some additional prerequisites should be satisfied before getting started with Cluster API. See below for the expected settings for common providers.

export AWS_REGION=us-east-1 # This is used to help encode your environment variables
export AWS_ACCESS_KEY_ID=<your-access-key>
export AWS_SECRET_ACCESS_KEY=<your-secret-access-key>
export AWS_SESSION_TOKEN=<session-token> # If you are using Multi-Factor Auth.

# The clusterawsadm utility takes the credentials that you set as environment
# variables and uses them to create a CloudFormation stack in your AWS account
# with the correct IAM resources.
clusterawsadm bootstrap iam create-cloudformation-stack

# Create the base64 encoded credentials using clusterawsadm.
# This command uses your environment variables and encodes
# them in a value to be stored in a Kubernetes Secret.
export AWS_B64ENCODED_CREDENTIALS=$(clusterawsadm bootstrap credentials encode-as-profile)

# Finally, initialize the management cluster
clusterctl init --infrastructure aws

export AZURE_SUBSCRIPTION_ID="<SubscriptionId>"

# Create an Azure Service Principal and paste the output here
export AZURE_TENANT_ID="<Tenant>"
export AZURE_CLIENT_ID="<AppId>"
export AZURE_CLIENT_SECRET="<Password>"

# Base64 encode the variables
export AZURE_SUBSCRIPTION_ID_B64="$(echo -n "$AZURE_SUBSCRIPTION_ID" | base64 | tr -d '\n')"
export AZURE_TENANT_ID_B64="$(echo -n "$AZURE_TENANT_ID" | base64 | tr -d '\n')"
export AZURE_CLIENT_ID_B64="$(echo -n "$AZURE_CLIENT_ID" | base64 | tr -d '\n')"
export AZURE_CLIENT_SECRET_B64="$(echo -n "$AZURE_CLIENT_SECRET" | base64 | tr -d '\n')"

# Settings needed for AzureClusterIdentity used by the AzureCluster
export AZURE_CLUSTER_IDENTITY_SECRET_NAME="cluster-identity-secret"
export CLUSTER_IDENTITY_NAME="cluster-identity"
export AZURE_CLUSTER_IDENTITY_SECRET_NAMESPACE="default"

# Create a secret to include the password of the Service Principal identity created in Azure
# This secret will be referenced by the AzureClusterIdentity used by the AzureCluster
kubectl create secret generic "${AZURE_CLUSTER_IDENTITY_SECRET_NAME}" --from-literal=clientSecret="${AZURE_CLIENT_SECRET}"

# Finally, initialize the management cluster
clusterctl init --infrastructure azure

export DIGITALOCEAN_ACCESS_TOKEN=<your-access-token>
export DO_B64ENCODED_CREDENTIALS="$(echo -n "${DIGITALOCEAN_ACCESS_TOKEN}" | base64 | tr -d '\n')"

# Initialize the management cluster
clusterctl init --infrastructure digitalocean

clusterctl init --infrastructure docker

export PACKET_API_KEY="34ts3g4s5g45gd45dhdh"

clusterctl init --infrastructure packet

# Create the base64 encoded credentials by catting your credentials json.
# This command uses your environment variables and encodes
# them in a value to be stored in a Kubernetes Secret.
export GCP_B64ENCODED_CREDENTIALS=$( cat /path/to/gcp-credentials.json | base64 | tr -d '\n' )

# Finally, initialize the management cluster
clusterctl init --infrastructure gcp

# Initialize the management cluster
clusterctl init --infrastructure openstack

# The username used to access the remote vSphere endpoint
export VSPHERE_USERNAME="vi-admin@vsphere.local"
# The password used to access the remote vSphere endpoint
# You may want to set this in ~/.cluster-api/clusterctl.yaml so your password is not in
# bash history
export VSPHERE_PASSWORD="admin!23"

# Finally, initialize the management cluster
clusterctl init --infrastructure vsphere

The output of clusterctl init is similar to this:

Fetching providers
Installing cert-manager Version="v1.5.3"
Waiting for cert-manager to be available...
Installing Provider="cluster-api" Version="v1.0.0" TargetNamespace="capi-system"
Installing Provider="bootstrap-kubeadm" Version="v1.0.0" TargetNamespace="capi-kubeadm-bootstrap-system"
Installing Provider="control-plane-kubeadm" Version="v1.0.0" TargetNamespace="capi-kubeadm-control-plane-system"
Installing Provider="infrastructure-docker" Version="v1.0.0" TargetNamespace="capd-system"

Your management cluster has been initialized successfully!

You can now create your first workload cluster by running the following:

  clusterctl generate cluster [name] --kubernetes-version [version] | kubectl apply -f -

Create your first workload cluster

Once the management cluster is ready, you can create your first workload cluster.

Preparing the workload cluster configuration

The clusterctl generate cluster command returns a YAML template for creating a workload cluster.

Required configuration for common providers

Depending on the infrastructure provider you are planning to use, some additional prerequisites should be satisfied before configuring a cluster with Cluster API. Instructions are provided for common providers below.

Otherwise, you can look at the clusterctl generate cluster command documentation for details about how to discover the list of variables required by a cluster templates.

export AWS_REGION=us-east-1
export AWS_SSH_KEY_NAME=default
# Select instance types
export AWS_CONTROL_PLANE_MACHINE_TYPE=t3.large
export AWS_NODE_MACHINE_TYPE=t3.large

# Name of the Azure datacenter location. Change this value to your desired location.
export AZURE_LOCATION="centralus"

# Select VM types.
export AZURE_CONTROL_PLANE_MACHINE_TYPE="Standard_D2s_v3"
export AZURE_NODE_MACHINE_TYPE="Standard_D2s_v3"

# [Optional] Select resource group. The default value is ${CLUSTER_NAME}.
export AZURE_RESOURCE_GROUP="<ResourceGroupName>"

export DO_REGION=nyc1
export DO_SSH_KEY_FINGERPRINT=<your-ssh-key-fingerprint>
export DO_CONTROL_PLANE_MACHINE_TYPE=s-2vcpu-2gb
export DO_CONTROL_PLANE_MACHINE_IMAGE=<your-capi-image-id>
export DO_NODE_MACHINE_TYPE=s-2vcpu-2gb
export DO_NODE_MACHINE_IMAGE==<your-capi-image-id>

# The list of service CIDR, default ["10.128.0.0/12"]
export SERVICE_CIDR=["10.96.0.0/12"]

# The list of pod CIDR, default ["192.168.0.0/16"]
export POD_CIDR=["192.168.0.0/16"]

# The service domain, default "cluster.local"
export SERVICE_DOMAIN="k8s.test"

# The project where your cluster will be placed to.
# You have to get one from the Equinix Metal Console if you don't have one already.
export PROJECT_ID="5yd4thd-5h35-5hwk-1111-125gjej40930"
# The facility where you want your cluster to be provisioned
export FACILITY="ewr1"
# The operatin system used to provision the device
export NODE_OS="ubuntu_18_04"
# The ssh key name you loaded in the Equinix Metal Console
export SSH_KEY="my-ssh"
export POD_CIDR="192.168.0.0/16"
export SERVICE_CIDR="172.26.0.0/16"
export CONTROLPLANE_NODE_TYPE="t1.small"
export WORKER_NODE_TYPE="t1.small"

# Name of the GCP datacenter location. Change this value to your desired location
export GCP_REGION="<GCP_REGION>"
export GCP_PROJECT="<GCP_PROJECT>"
# Make sure to use same kubernetes version here as building the GCE image
export KUBERNETES_VERSION=1.23.3
# This is the image you built. See https://github.com/kubernetes-sigs/image-builder
export IMAGE_ID=projects/$GCP_PROJECT/global/images/<built image>
export GCP_CONTROL_PLANE_MACHINE_TYPE=n1-standard-2
export GCP_NODE_MACHINE_TYPE=n1-standard-2
export GCP_NETWORK_NAME=<GCP_NETWORK_NAME or default>
export CLUSTER_NAME="<CLUSTER_NAME>"

# The URL of the kernel to deploy.
export DEPLOY_KERNEL_URL="http://172.22.0.1:6180/images/ironic-python-agent.kernel"
# The URL of the ramdisk to deploy.
export DEPLOY_RAMDISK_URL="http://172.22.0.1:6180/images/ironic-python-agent.initramfs"
# The URL of the Ironic endpoint.
export IRONIC_URL="http://172.22.0.1:6385/v1/"
# The URL of the Ironic inspector endpoint.
export IRONIC_INSPECTOR_URL="http://172.22.0.1:5050/v1/"
# Do not use a dedicated CA certificate for Ironic API. Any value provided in this variable disables additional CA certificate validation.
# To provide a CA certificate, leave this variable unset. If unset, then IRONIC_CA_CERT_B64 must be set.
export IRONIC_NO_CA_CERT=true
# Disables basic authentication for Ironic API. Any value provided in this variable disables authentication.
# To enable authentication, leave this variable unset. If unset, then IRONIC_USERNAME and IRONIC_PASSWORD must be set.
export IRONIC_NO_BASIC_AUTH=true
# Disables basic authentication for Ironic inspector API. Any value provided in this variable disables authentication.
# To enable authentication, leave this variable unset. If unset, then IRONIC_INSPECTOR_USERNAME and IRONIC_INSPECTOR_PASSWORD must be set.
export IRONIC_INSPECTOR_NO_BASIC_AUTH=true

clusterctl generate cluster --infrastructure nutanix --list-variables capi-quickstart

clusterctl generate cluster --infrastructure openstack --list-variables capi-quickstart

wget https://raw.githubusercontent.com/kubernetes-sigs/cluster-api-provider-openstack/master/templates/env.rc -O /tmp/env.rc
source /tmp/env.rc <path/to/clouds.yaml> <cloud>

# The list of nameservers for OpenStack Subnet being created.
# Set this value when you need create a new network/subnet while the access through DNS is required.
export OPENSTACK_DNS_NAMESERVERS=<dns nameserver>
# FailureDomain is the failure domain the machine will be created in.
export OPENSTACK_FAILURE_DOMAIN=<availability zone name>
# The flavor reference for the flavor for your server instance.
export OPENSTACK_CONTROL_PLANE_MACHINE_FLAVOR=<flavor>
# The flavor reference for the flavor for your server instance.
export OPENSTACK_NODE_MACHINE_FLAVOR=<flavor>
# The name of the image to use for your server instance. If the RootVolume is specified, this will be ignored and use rootVolume directly.
export OPENSTACK_IMAGE_NAME=<image name>
# The SSH key pair name
export OPENSTACK_SSH_KEY_NAME=<ssh key pair name>
# The external network
export OPENSTACK_EXTERNAL_NETWORK_ID=<external network ID>

# The vCenter server IP or FQDN
export VSPHERE_SERVER="10.0.0.1"
# The vSphere datacenter to deploy the management cluster on
export VSPHERE_DATACENTER="SDDC-Datacenter"
# The vSphere datastore to deploy the management cluster on
export VSPHERE_DATASTORE="vsanDatastore"
# The VM network to deploy the management cluster on
export VSPHERE_NETWORK="VM Network"
# The vSphere resource pool for your VMs
export VSPHERE_RESOURCE_POOL="*/Resources"
# The VM folder for your VMs. Set to "" to use the root vSphere folder
export VSPHERE_FOLDER="vm"
# The VM template to use for your VMs
export VSPHERE_TEMPLATE="ubuntu-1804-kube-v1.17.3"
# The public ssh authorized key on all machines
export VSPHERE_SSH_AUTHORIZED_KEY="ssh-rsa AAAAB3N..."
# The certificate thumbprint for the vCenter server
export VSPHERE_TLS_THUMBPRINT="97:48:03:8D:78:A9..."
# The storage policy to be used (optional). Set to "" if not required
export VSPHERE_STORAGE_POLICY="policy-one"
# The IP address used for the control plane endpoint
export CONTROL_PLANE_ENDPOINT_IP="1.2.3.4"

Generating the cluster configuration

For the purpose of this tutorial, we’ll name our cluster capi-quickstart.

clusterctl generate cluster capi-quickstart \
  --kubernetes-version v1.23.3 \
  --control-plane-machine-count=3 \
  --worker-machine-count=3 \
  > capi-quickstart.yaml

clusterctl generate cluster capi-quickstart --flavor development \
  --kubernetes-version v1.23.3 \
  --control-plane-machine-count=3 \
  --worker-machine-count=3 \
  > capi-quickstart.yaml

clusterctl generate cluster capi-quickstart --flavor development-topology \
  --kubernetes-version v1.23.3 \
  --control-plane-machine-count=3 \
  --worker-machine-count=3 \
  > capi-quickstart.yaml

This creates a YAML file named capi-quickstart.yaml with a predefined list of Cluster API objects; Cluster, Machines, Machine Deployments, etc.

The file can be eventually modified using your editor of choice.

See clusterctl generate cluster for more details.

Apply the workload cluster

When ready, run the following command to apply the cluster manifest.

kubectl apply -f capi-quickstart.yaml

The output is similar to this:

cluster.cluster.x-k8s.io/capi-quickstart created
dockercluster.infrastructure.cluster.x-k8s.io/capi-quickstart created
kubeadmcontrolplane.controlplane.cluster.x-k8s.io/capi-quickstart-control-plane created
dockermachinetemplate.infrastructure.cluster.x-k8s.io/capi-quickstart-control-plane created
machinedeployment.cluster.x-k8s.io/capi-quickstart-md-0 created
dockermachinetemplate.infrastructure.cluster.x-k8s.io/capi-quickstart-md-0 created
kubeadmconfigtemplate.bootstrap.cluster.x-k8s.io/capi-quickstart-md-0 created

Accessing the workload cluster

The cluster will now start provisioning. You can check status with:

kubectl get cluster

You can also get an “at glance” view of the cluster and its resources by running:

clusterctl describe cluster capi-quickstart

To verify the first control plane is up:

kubectl get kubeadmcontrolplane

You should see an output is similar to this:

NAME                            INITIALIZED   API SERVER AVAILABLE   VERSION   REPLICAS   READY   UPDATED   UNAVAILABLE
capi-quickstart-control-plane   true                                 v1.23.3   3                  3         3

After the first control plane node is up and running, we can retrieve the workload cluster Kubeconfig:

clusterctl get kubeconfig capi-quickstart > capi-quickstart.kubeconfig

Deploy a CNI solution

Calico is used here as an example.

kubectl --kubeconfig=./capi-quickstart.kubeconfig \
  apply -f https://docs.projectcalico.org/v3.21/manifests/calico.yaml

kubectl --kubeconfig=./capi-quickstart.kubeconfig get nodes

kubectl --kubeconfig=./capi-quickstart.kubeconfig \
  apply -f https://raw.githubusercontent.com/kubernetes-sigs/cluster-api-provider-azure/main/templates/addons/calico.yaml

kubectl --kubeconfig=./capi-quickstart.kubeconfig get nodes

Clean Up

Delete workload cluster.

kubectl delete cluster capi-quickstart

Delete management cluster

kind delete cluster

Next steps

See the clusterctl documentation for more detail about clusterctl supported actions.

Pre-built Kubernetes AMIs

New AMIs are built whenever a new Kubernetes version is released for each supported OS distribution and then published to supported regions.

clusterawsadm ami list command lists pre-built AMIs by Kubernetes version, OS, or AWS region. See clusterawsadm ami list for details.

Supported OS Distributions

• Amazon Linux 2 (amazon-2)
• Ubuntu (ubuntu-20.04, ubuntu-18.04)
• Centos (centos-7)

Supported AWS Regions

• ap-northeast-1
• ap-northeast-2
• ap-south-1
• ap-southeast-1
• ap-northeast-2
• ca-central-1
• eu-central-1
• eu-west-1
• eu-west-2
• eu-west-3
• sa-east-1
• us-east-1
• us-east-2
• us-west-1
• us-west-2

Most recent AMIs

Topics

Using clusterawsadm to fulfill prerequisites

Requirements

• Linux or MacOS (Windows isn’t supported at the moment).
• AWS credentials.
• AWS CLI
• jq

IAM resources

With clusterawsadm

Get the latest clusterawsadm and place it in your path.

Cluster API Provider AWS ships with clusterawsadm, a utility to help you manage IAM objects for this project.

In order to use clusterawsadm you must have an administrative user in an AWS account. Once you have that administrator user you need to set your environment variables:

• AWS_REGION
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY
• AWS_SESSION_TOKEN (if you are using Multi-factor authentication)

After these are set run this command to get you up and running:

clusterawsadm bootstrap iam create-cloudformation-stack

Additional policies can be added by creating a configuration file

apiVersion: bootstrap.aws.infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSIAMConfiguration
spec:
  controlPlane:
    ExtraPolicyAttachments:
      - arn:aws:iam::<AWS_ACCOUNT>:policy/my-policy
      - arn:aws:iam::aws:policy/AmazonEC2FullAccess
  nodes:
    ExtraPolicyAttachments:
      - arn:aws:iam::<AWS_ACCOUNT>:policy/my-other-policy

and passing it to clusterawsadm as follows

clusterawsadm bootstrap iam create-cloudformation-stack --config bootstrap-config.yaml

These will be added to the control plane and node roles respectively when they are created.

Note: If you used the now deprecated clusterawsadm alpha bootstrap 0.5.4 or earlier to create IAM objects for the Cluster API Provider for AWS, using clusterawsadm bootstrap iam 0.5.5 or later will, by default, remove the bootstrap user and group. Anything using those credentials to authenticate will start experiencing authentication failures. If you rely on the bootstrap user and group credentials, specify bootstrapUser.enable = true in the configuration file, like this:

apiVersion: bootstrap.aws.infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSIAMConfiguration
spec:
  bootstrapUser:
    enable: true

With EKS Support

The pre-requisities for EKS are enabled by default. However, if you want to use some of the optional features of EKS (see here for more information on what these are) then you will need to enable these features via the configuration file. For example:

apiVersion: bootstrap.aws.infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSIAMConfiguration
spec:
  eks:
    iamRoleCreation: false # Set to true if you plan to use the EKSEnableIAM feature flag to enable automatic creation of IAM roles
    managedMachinePool:
      disable: false # Set to false to enable creation of the default node role for managed machine pools
    fargate:
      disable: false # Set to false to enable creation of the default role for the fargate profiles

and then use that configuration file:

clusterawsadm bootstrap iam create-cloudformation-stack --config bootstrap-config.yaml

Enabling EventBridge Events

To enable EventBridge instance state events, additional permissions must be granted along with enabling the feature-flag. Additional permissions for events and queue management can be enabled through the configuration file as follows:

apiVersion: bootstrap.aws.infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSIAMConfiguration
spec:
  ...
  eventBridge:
    enable: true
  ...

Without clusterawsadm

This is not a recommended route as the policies are very specific and will change with new features.

If you do not wish to use the clusteradwsadm tool then you will need to understand exactly which IAM policies and groups we are expecting. There are several policies, roles and users that need to be created. Please see our controller policy file to understand the permissions that are necessary.

You can use clusteradwadm to print out the needed IAM policies, e.g.

clusterawsadm bootstrap iam print-policy --document AWSIAMManagedPolicyControllers --config bootstrap-config.yaml

SSH Key pair

If you plan to use SSH to access the instances created by Cluster API Provider AWS then you will need to specify the name of an existing SSH key pair within the region you plan on using. If you don’t have one yet, a new one needs to be created.

Create a new key pair

# Save the output to a secure location
aws ec2 create-key-pair --key-name default | jq .KeyMaterial -r
-----BEGIN RSA PRIVATE KEY-----
[... contents omitted ...]
-----END RSA PRIVATE KEY-----

If you want to save the private key directly into AWS Systems Manager Parameter Store with KMS encryption for security, you can use the following command:

aws ssm put-parameter --name "/sigs.k8s.io/cluster-api-provider-aws/ssh-key" \
  --type SecureString \
  --value "$(aws ec2 create-key-pair --key-name default | jq .KeyMaterial -r)"

Adding an existing public key to AWS

# Replace with your own public key
aws ec2 import-key-pair \
  --key-name default \
  --public-key-material "$(cat ~/.ssh/id_rsa.pub)"

NB: Only RSA keys are supported by AWS.

Setting up the environment

The current iteration of the Cluster API Provider AWS relies on credentials being present in your environment. These then get written into the cluster manifests for use by the controllers.

E.g.

export AWS_REGION=us-east-1 # This is used to help encode your environment variables
export AWS_ACCESS_KEY_ID=<your-access-key>
export AWS_SECRET_ACCESS_KEY=<your-secret-access-key>
export AWS_SESSION_TOKEN=<session-token> # If you are using Multi-Factor Auth.

Note: The credentials used must have the appropriate permissions for use by the controllers. You can get the required policy statement by using the following command:

clusterawsadm bootstrap iam print-policy --document AWSIAMManagedPolicyControllers --config bootstrap-config.yaml

To save credentials securely in your environment, aws-vault uses the OS keystore as permanent storage, and offers shell features to securely expose and setup local AWS environments.

Accessing cluster instances

Overview

After running clusterctl generate cluster to generate the configuration for a new workload cluster (and then redirecting that output to a file for use with kubectl apply, or piping it directly to kubectl apply), the new workload cluster will be deployed. This document explains how to access the new workload cluster’s nodes.

Prerequisites

1. clusterctl generate cluster was successfully executed to generate the configuration for a new workload cluster
2. The configuration for the new workload cluster was applied to the management cluster using kubectl apply and the cluster is up and running in an AWS environment.
3. The SSH key referenced by clusterctl in step 1 exists in AWS and is stored in the correct location locally for use by SSH (on macOS/Linux systems, this is typically $HOME/.ssh). This document will refer to this key as cluster-api-provider-aws.sigs.k8s.io.
4. (If using AWS Session Manager) The AWS CLI and the Session Manager plugin have been installed and configured.

Methods for accessing nodes

There are two ways to access cluster nodes once the workload cluster is up and running:

• via SSH
• via AWS Session Manager

Accessing nodes via SSH

By default, workload clusters created in AWS will not support access via SSH apart from AWS Session Manager (see the section titled “Accessing nodes via AWS Session Manager”). However, the manifest for a workload cluster can be modified to include an SSH bastion host, created and managed by the management cluster, to enable SSH access to cluster nodes. The bastion node is created in a public subnet and provides SSH access from the world. It runs the official Ubuntu Linux image.

Enabling the bastion host

To configure the Cluster API Provider for AWS to create an SSH bastion host, add this line to the AWSCluster spec:

spec:
  bastion:
    enabled: true

Obtain public IP address of the bastion node

Once the workload cluster is up and running after being configured for an SSH bastion host, you can use the kubectl get awscluster command to look up the public IP address of the bastion host (make sure the kubectl context is set to the management cluster). The output will look something like this:

NAME   CLUSTER   READY   VPC                     BASTION IP
test   test      true    vpc-1739285ed052be7ad   1.2.3.4

Setting up the SSH key path

Assumming that the cluster-api-provider-aws.sigs.k8s.io SSH key is stored in $HOME/.ssh/cluster-api-provider-aws, use this command to set up an environment variable for use in a later command:

export CLUSTER_SSH_KEY=$HOME/.ssh/cluster-api-provider-aws

Get private IP addresses of nodes in the cluster

To get the private IP addresses of nodes in the cluster (nodes may be control plane nodes or worker nodes), use this kubectl command with the context set to the management cluster:

kubectl get nodes -o custom-columns=NAME:.metadata.name,\
IP:"{.status.addresses[?(@.type=='InternalIP')].address}"

This will produce output that looks like this:

NAME                                         IP
ip-10-0-0-16.us-west-2.compute.internal   10.0.0.16
ip-10-0-0-68.us-west-2.compute.internal   10.0.0.68

The above command returns IP addresses of the nodes in the cluster. In this case, the values returned are 10.0.0.16 and 10.0.0.68.

Connecting to the nodes via SSH

To access one of the nodes (either a control plane node or a worker node) via the SSH bastion host, use this command if you are using a non-EKS cluster:

ssh -i ${CLUSTER_SSH_KEY} ubuntu@<NODE_IP> \
	-o "ProxyCommand ssh -W %h:%p -i ${CLUSTER_SSH_KEY} ubuntu@${BASTION_HOST}"

And use this command if you are using a EKS based cluster:

ssh -i ${CLUSTER_SSH_KEY} ec2-user@<NODE_IP> \
	-o "ProxyCommand ssh -W %h:%p -i ${CLUSTER_SSH_KEY} ubuntu@${BASTION_HOST}"

If the whole document is followed, the value of <NODE_IP> will be either 10.0.0.16 or 10.0.0.68.

Alternately, users can add a configuration stanza to their SSH configuration file (typically found on macOS/Linux systems as $HOME/.ssh/config):

Host 10.0.*
  User ubuntu
  IdentityFile <CLUSTER_SSH_KEY>
  ProxyCommand ssh -W %h:%p ubuntu@<BASTION_HOST>

Accessing nodes via AWS Session Manager

All CAPA-published AMIs based on Ubuntu have the AWS SSM Agent pre-installed (as a Snap package; this was added in June 2018 to the base Ubuntu Server image for all 16.04 and later AMIs). This allows users to access cluster nodes directly, without the need for an SSH bastion host, using the AWS CLI and the Session Manager plugin.

To access a cluster node (control plane node or worker node), you’ll need the instance ID. You can retrieve the instance ID using this kubectl command with the context set to the management cluster:

kubectl get awsmachines -o custom-columns=NAME:.metadata.name,INSTANCEID:.spec.providerID

This will produce output similar to this:

NAME                      INSTANCEID
test-controlplane-52fhh   aws:////i-112bac41a19da1819
test-controlplane-lc5xz   aws:////i-99aaef2381ada9228

Users can then use the instance ID (everything after the aws://// prefix) to connect to the cluster node with this command:

aws ssm start-session --target <INSTANCE_ID>

This will log you into the cluster node as the ssm-user user ID.

Additional Notes

Using the AWS CLI instead of kubectl

It is also possible to use AWS CLI commands instead of kubectl to gather information about the cluster nodes.

For example, to use the AWS CLI to get the public IP address of the SSH bastion host, use this AWS CLI command:

export BASTION_HOST=$(aws ec2 describe-instances --filter='Name=tag:Name,Values=<CLUSTER_NAME>-bastion' \
	| jq '.Reservations[].Instances[].PublicIpAddress' -r)

You should substitute the correct cluster name for <CLUSTER_NAME> in the above command. (NOTE: If make manifests was used to generate manifests, by default the <CLUSTER_NAME> is set to test1.)

Similarly, to obtain the list of private IP addresses of the cluster nodes, use this AWS CLI command:

for type in control-plane node
do
	aws ec2 describe-instances \
    --filter="Name=tag:sigs.k8s.io/cluster-api-provider-aws/role,\
    Values=${type}" \
		| jq '.Reservations[].Instances[].PrivateIpAddress' -r
done
10.0.0.16
10.0.0.68

Finally, to obtain AWS instance IDs for cluster nodes, you can use this AWS CLI command:

for type in control-plane node
do
	aws ec2 describe-instances \
    --filter="Name=tag:sigs.k8s.io/cluster-api-provider-aws/role,\
    Values=${type}" \
		| jq '.Reservations[].Instances[].InstanceId' -r
done
i-112bac41a19da1819
i-99aaef2381ada9228

Note that your AWS CLI must be configured with credentials that enable you to query the AWS EC2 API.

MachinePools

• Feature status: Experimental
• Feature gate: MachinePool=true

MachinePool allows users to manage many machines as a single entity. Infrastructure providers implement a separate CRD that handles infrastructure side of the feature.

AWSMachinePool

Cluster API Provider AWS (CAPA) has experimental support for MachinePool though the infrastructure type AWSMachinePool. An AWSMachinePool corresponds to an AWS AutoScaling Groups, which provides the cloud provider specific resource for orchestrating a group of EC2 machines.

The AWSMachinePool controller creates and manages an AWS AutoScaling Group using launch templates so users don’t have to manage individual machines. You can use Autoscaling health checks for replacing instances and it will maintain the number of instances specified.

Using clusterctl to deploy

To deploy a MachinePool / AWSMachinePool via clusterctl generate there’s a flavor for that.

Make sure to set up your AWS environment as described here.

export EXP_MACHINE_POOL=true
clusterctl init --infrastructure aws
clusterctl generate cluster my-cluster --kubernetes-version v1.16.8 --flavor machinepool > my-cluster.yaml

The template used for this flavor is located here.

AWSManagedMachinePool

Cluster API Provider AWS (CAPA) has experimental support for EKS Managed Node Groups using MachinePool through the infrastructure type AWSManagedMachinePool. An AWSManagedMachinePool corresponds to an AWS AutoScaling Groups that is used for an EKS managed node group. .

The AWSManagedMachinePool controller creates and manages an EKS managed node group with in turn manages an AWS AutoScaling Group of managed EC2 instance types.

To use the managed machine pools certain IAM permissions are needed. The easiest way to ensure the required IAM permissions are in place is to use clusterawsadm to create them. To do this, follow the EKS instructions in using clusterawsadm to fulfill prerequisites.

Using clusterctl to deploy

To deploy an EKS managed node group using AWSManagedMachinePool via clusterctl generate you can use a flavor.

Make sure to set up your AWS environment as described here.

export EXP_MACHINE_POOL=true
clusterctl init --infrastructure aws
clusterctl generate cluster my-cluster --kubernetes-version v1.16.8 --flavor eks-managedmachinepool > my-cluster.yaml

The template used for this flavor is located here.

Examples

Example MachinePool, AWSMachinePool and KubeadmConfig Resources

Below is an example of the resources needed to create a pool of EC2 machines orchestrated with an AWS Auto Scaling Group.

---
apiVersion: cluster.x-k8s.io/v1beta1
kind: MachinePool
metadata:
  name: capa-mp-0
spec:
  clusterName: capa
  replicas: 2
  template:
    spec:
      bootstrap:
        configRef:
          apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
          kind: KubeadmConfig
          name: capa-mp-0
      clusterName: capa
      infrastructureRef:
        apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
        kind: AWSMachinePool
        name: capa-mp-0
      version: v1.16.8
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSMachinePool
metadata:
  name: capa-mp-0
spec:
  minSize: 1
  maxSize: 10
  availabilityZones:
    - us-east-1
  awsLaunchTemplate:
    instanceType: "${AWS_CONTROL_PLANE_MACHINE_TYPE}"
    sshKeyName: "${AWS_SSH_KEY_NAME}"
  subnets:
  - ${AWS_SUBNET}
---
apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
kind: KubeadmConfig
metadata:
  name: capa-mp-0
  namespace: default
spec:
  joinConfiguration:
    nodeRegistration:
      name: '{{ ds.meta_data.local_hostname }}'
      kubeletExtraArgs:
        cloud-provider: aws

Multi-tenancy

Starting from v0.6.5, single controller multi-tenancy is supported that allows using a different AWS Identity for each workload cluster. For details, see the multi-tenancy proposal.

For multi-tenancy support, a reference field (identityRef) is added to AWSCluster, which describes the identity to be used when reconciling the cluster.

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSCluster
metadata:
  name: "test"
  namespace: "test"
spec:
  region: "eu-west-1"
  identityRef:
    kind: <IdentityType>
    name: <IdentityName>

Identity resources are used to describe IAM identities that will be used during reconciliation. There are three identity types: AWSClusterControllerIdentity, AWSClusterStaticIdentity, and AWSClusterRoleIdentity. Once an IAM identity is created in AWS, the corresponding values should be used to create a identity resource.

AWSClusterControllerIdentity

Before multi-tenancy support, all AWSClusters were being reconciled using the credentials that are used by Cluster API Provider AWS Controllers. AWSClusterControllerIdentity is used to restrict the usage of controller credentials only to AWSClusters that are in allowedNamespaces. Since CAPA controllers use a single set of credentials, AWSClusterControllerIdentity is a singleton, and can only be created with name: default.

For backward compatibility, AutoControllerIdentityCreator experimental feature is added, which is responsible to create the AWSClusterControllerIdentity singleton if it does not exist.

• Feature status: Experimental
• Feature gate: AutoControllerIdentityCreator=true AutoControllerIdentityCreator creates AWSClusterControllerIdentity singleton with empty allowedNamespaces (allowedNamespaces: {}) to grant access to the AWSClusterControllerIdentity from all namespaces.

Example:

---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSCluster
metadata:
  name: "test"
  namespace: "test"
spec:
  region: "eu-west-1"
  identityRef:
    kind: AWSClusterControllerIdentity
    name: default
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSClusterControllerIdentity
metadata:
  name: "default"
spec:
  allowedNamespaces:{}  # matches all namespaces

AWSClusterControllerIdentity is immutable to avoid any unwanted overrides to the allowed namespaces, especially during upgrading clusters.

AWSClusterStaticIdentity

AWSClusterStaticIdentity represents static AWS credentials, which are stored in a Secret.

Example: Below, an AWSClusterStaticIdentity is created that allows access to the AWSClusters that are in “test” namespace. The identity credentials that will be used by “test” AWSCluster are stored in “test-account-creds” secret.

---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSCluster
metadata:
  name: "test"
  namespace: "test"
spec:
  region: "eu-west-1"
  identityRef:
    kind: AWSClusterStaticIdentity
    name: test-account
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSClusterStaticIdentity
metadata:
  name: "test-account"
spec:
  secretRef:
    name: test-account-creds
    namespace: capa-system
  allowedNamespaces:
    selector:
      matchLabels:
        cluster.x-k8s.io/ns: "testlabel"
---
apiVersion: v1
kind: Namespace
metadata:
  labels:
    cluster.x-k8s.io/ns: "testlabel"
  name: "test"
---
apiVersion: v1
kind: Secret
metadata:
  name: "test-account-creds"
  namespace: capa-system
stringData:
 AccessKeyID: AKIAIOSFODNN7EXAMPLE
 SecretAccessKey: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

AWSClusterRoleIdentity

AWSClusterRoleIdentity allows CAPA to assume a role either in the same or another AWS account, using the STS::AssumeRole API. The assumed role could be used by the AWSClusters that is in the allowedNamespaces.

Example: Below, an AWSClusterRoleIdentity instance, which will be used by AWSCluster “test”, is created. This role will be assumed by the source identity at runtime. Source identity can be of any identity type. Role is assumed in the beginning once and after, whenever the assumed role’s credentials are expired.

---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSCluster
metadata:
  name: "test"
  namespace: "test"
spec:
  region: "eu-west-1"
  identityRef:
    kind: AWSClusterRoleIdentity
    name: test-account-role
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSClusterRoleIdentity
metadata:
  name: "test-account-role"
spec:
  allowedNamespaces:
    list: # allows only "test" namespace to use this identity
      "test"
  roleARN: "arn:aws:iam::123456789:role/CAPARole"
  sourceIdentityRef:
    kind: AWSClusterStaticIdentity
    name: test-account-creds

Nested role assumption is also supported. Example: Below, “multi-tenancy-nested-role” will be assumed by “multi-tenancy-role”, which will be assumed by the “default” AWSClusterControllerIdentity

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSClusterRoleIdentity
metadata:
  name: multi-tenancy-role
spec:
  allowedNamespaces:
    list: []
  durationSeconds: 900 # default and min value is 900 seconds
  roleARN: arn:aws:iam::11122233344:role/multi-tenancy-role
  sessionName: multi-tenancy-role-session
  sourceidentityRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: AWSClusterControllerIdentity
    name: default
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSClusterRoleIdentity
metadata:
  name: multi-tenancy-nested-role
spec:
  allowedNamespaces:
    list: []
  roleARN: arn:aws:iam::11122233355:role/multi-tenancy-nested-role
  sessionName: multi-tenancy-nested-role-session
  sourceidentityRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: AWSClusterRoleIdentity
    name: multi-tenancy-role

Secure Access to Identitys

allowedNamespaces field is used to grant access to the namespaces to use Identitys. Only AWSClusters that are created in one of the Identity’s allowed namespaces can use that Identity. allowedNamespaces are defined by providing either a list of namespaces or label selector to select namespaces.

Note that the capa-eks-control-plane-system namespace will need to be included in the allow namespace list and/or have labels added to allow access to identities used by AWSClusters.

Examples

An empty allowedNamespaces indicates that the Identity can be used by all namespaces.

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSClusterControllerIdentity
spec:
  allowedNamespaces:{}  # matches all namespaces

Having a nil list and a nil selector is the same with having an empty allowedNamespaces (Identity can be used by all namespaces).

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSClusterControllerIdentity
spec:
  allowedNamespaces:
    list: nil
    selector: nil

A nil allowedNamespaces indicates that the Identity cannot be used from any namespace.

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSClusterControllerIdentity
spec:
  allowedNamespaces:  # this is same with not providing the field at all or allowedNamespaces: null

The union of namespaces that are matched by selector and the namespaces that are in the list is granted access to the identity. The namespaces that are not in the list and not matching the selector will not have access.

Nil or empty list matches no namespaces. Nil or empty selector matches no namespaces. If list is nil and selector is empty OR list is empty and selector is nil, Identity cannot be used from any namespace. Because in this case, allowedNamespaces is not empty or nil, and neither list nor selector allows any namespaces, so the union is empty.

# Matches no namespaces
allowedNamespaces:
  list: []

# Matches no namespaces
allowedNamespaces:
  selector: {}

# Matches no namespaces
allowedNamespaces:
  list: null
  selector: {}

# Matches no namespaces
allowedNamespaces:
  list: []
  selector: {}

Important The default behaviour of an empty label selector is to match all objects, however here we do not follow that behavior to avoid unintended access to the identitys. This is consistent with core cluster API selectors, e.g., Machine and ClusterResourceSet selectors. The result of matchLabels and matchExpressions are ANDed.

In Kubernetes selectors, matchLabels and matchExpressions are ANDed. In the example below, list is empty/nil, so does not allow any namespaces and selector matches with only default namespace. Since list and selector results are ORed, default namespace can use this identity.

kind: namespace
metadata:
  name: default
  labels:
    environment: dev
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSClusterControllerIdentity
spec:
  allowedNamespaces:
    list: null # or []
    selector:
      matchLabels:
        namespace: default
      matchExpressions:
        - {key: environment, operator: In, values: [dev]}

EKS Support in the AWS Provider

• Feature status: Stable
• Feature gate (required): EKS=true
• Feature gate (optional): EKSEnableIAM=true,EKSAllowAddRoles=true

Overview

The AWS provider supports creating EKS based cluster. Currently the following features are supported:

• Provisioning/managing an Amazon EKS Cluster
• Upgrading the Kubernetes version of the EKS Cluster
• Attaching a self-managed machines as nodes to the EKS cluster
• Creating a machine pool and attaching it to the EKS cluster. See machine pool docs for details.
• Creating a managed machine pool and attaching it to the EKS cluster. See machine pool docs for details
• Managing “EKS Addons”. See addons for further details
• Creating an EKS fargate profile
• Managing aws-iam-authenticator configuration

Note: machine pools and fargate profiles are still classed as experimental.

The implementation introduces the following CRD kinds:

• AWSManagedControlPlane - specifies the EKS Cluster in AWS and used by the Cluster API AWS Managed Control plane (MACP)
• AWSManagedMachinePool - defines the managed node pool for the cluster
• EKSConfig - used by Cluster API bootstrap provider EKS (CABPE)

And a number of new templates are available in the templates folder for creating a managed workload cluster.

SEE ALSO

• Prerequisites
• Enabling EKS Support
• Disabling EKS Support
• Creating a cluster
• Using EKS Console
• Using EKS Addons
• Enabling Encryption
• Cluster Upgrades

Prerequisites

To use EKS you must give the controller the required permissions. The easiest way to do this is by using clusterawasadm. For instructions on how to do this see the prerequisites.

When using clusterawsadm and enabling EKS support a new IAM role will be created for you called eks-controlplane.cluster-api-provider-aws.sigs.k8s.io. This role is the IAM role that will be used for the EKS control plane if you don’t specify your own role and if EKSEnableIAM isn’t enabled (see the enabling docs for further information).

Additionally using clusterawsadm will add permissions to the controllers.cluster-api-provider-aws.sigs.k8s.io policy for EKS to function properly.

Enabling EKS Support

Support for EKS is enabled by default when you use the AWS infrastructure provider. For example:

clusterctl init --infrastructure aws

Enabling optional EKS features

There are additional EKS experimental features that are disabled by default. The sections below cover how to enable these features.

Machine Pools

To enable support for machine pools the MachinePool feature flag must be set to to true. This can be done using the EXP_MACHINE_POOL environment variable:

export EXP_MACHINE_POOL=true
clusterctl init --infrastructure aws

See the machine pool documentation for further information.

NOTE: you will need to enable the creation of the default IAM role. The easiest way is using clusterawsadm, for instructions see the prerequisites.

IAM Roles Per Cluster

By default EKS clusters will use the same IAM roles (i.e. control plane, node group roles). There is a feature that allows each cluster to have its own IAM roles. This is done by enabling the EKSEnableIAM feature flag. This can be done before running clusterctl init by using the the CAPA_EKS_IAM environment variable:

export CAPA_EKS_IAM=true
clusterctl init --infrastructure aws

NOTE: you will need the correct prerequisities for this. The easiest way is using clusterawsadm and setting iamRoleCreation to true, for instructions see the prerequisites.

Additional Control Plane Roles

You can add additional roles to the control plane role that is created for an EKS cluster. To use this you must enable the EKSAllowAddRoles feature flag. This can be done before running clusterctl init by using the CAPA_EKS_ADD_ROLES environment variable:

export CAPA_EKS_IAM=true
export CAPA_EKS_ADD_ROLES=true
clusterctl init --infrastructure aws

NOTE: to use this feature you must also enable the CAPA_EKS_IAM feature.

EKS Fargate Profiles

You can use Fargate Profiles with EKS. To use this you must enable the EKSFargate feature flag. This can be done before running clusterctl init by using the EXP_EKS_FARGATE environmnet variable:

export EXP_EKS_FARGATE=true
clusterctl init --infrastructure aws

NOTE: you will need to enable the creation of the default Fargate IAM role. The easiest way is using clusterawsadm and using the fargate configuration option, for instructions see the prerequisites.

Pod Networking

When creating a EKS cluster the Amazon VPC CNI will be used by default for Pod Networking.

When using the AWS Console to create an EKS cluster with a Kubernetes version of v1.18 or greater you are required to select a specific version of the VPC CNI to use.

Using the VPC CNI Addon

You can use an explicit version of the Amazon VPC CNI by using the vpc-cni EKS addon. See the addons documentation for further details of how to use addons.

Using an alternative CNI

There may be scenarios where you do not want to use the Amazon VPC CNI. EKS supports a number of alternative CNIs such as Calico and Weave Net (see docs for full list).

There are a number of ways to install an alternative CNI into the cluster. One option is to use a ClusterResourceSet to apply the required artifacts to a newly provisioned cluster.

When using an alternative CNI you will want to delete the Amazon VPC CNI, especially for a cluster using v1.17 or less. This can be done via the disableVPCCNI property of the AWSManagedControlPlane:

kind: AWSManagedControlPlane
apiVersion: controlplane.cluster.x-k8s.io/v1beta1
metadata:
  name: "capi-managed-test-control-plane"
spec:
  region: "eu-west-2"
  sshKeyName: "capi-management"
  version: "v1.18.0"
  disableVPCCNI: true

You cannot set disableVPCCNI to true if you are using the VPC CNI addon or if you have specified a secondary CIDR block.

Additional Information

See the AWS documentation for further details of EKS pod networking.

Creating a EKS cluster

New “eks” cluster templates have been created that you can use with clusterctl to create a EKS cluster. To create a EKS cluster with self-managed nodes (a.k.a machines):

clusterctl generate cluster capi-eks-quickstart --flavor eks --kubernetes-version v1.17.3 --worker-machine-count=3 > capi-eks-quickstart.yaml

To create a EKS cluster with a managed node group (a.k.a managed machine pool):

clusterctl generate cluster capi-eks-quickstart --flavor eks-managedmachinepool --kubernetes-version v1.17.3 --worker-machine-count=3 > capi-eks-quickstart.yaml

NOTE: When creating an EKS cluster only the MAJOR.MINOR of the -kubernetes-version is taken into consideration.

Kubeconfig

When creating an EKS cluster 2 kubeconfigs are generated and stored as secrets in the managmenet cluster. This is different to when you create a non-managed cluster using the AWS provider.

User kubeconfig

This should be used by users that want to connect to the newly created EKS cluster. The name of the secret that contains the kubeconfig will be [cluster-name]-user-kubeconfig where you need to replace [cluster-name] with the name of your cluster. The -user-kubeconfig in the name indicates that the kubeconfig is for the user use.

To get the user kubeconfig for a cluster named managed-test you can run a command similar to:

kubectl --namespace=default get secret managed-test-user-kubeconfig \
   -o jsonpath={.data.value} | base64 --decode \
   > managed-test.kubeconfig

Cluster API (CAPI) kubeconfig

This kubeconfig is used internally by CAPI and shouldn’t be used outside of the management server. It is used by CAPI to perform operations, such as draining a node. The name of the secret that contains the kubeconfig will be [cluster-name]-kubeconfig where you need to replace [cluster-name] with the name of your cluster. Note that there is NO -user in the name.

The kubeconfig is regenerated every sync-period as the token that is embedded in the kubeconfig is only valid for a short period of time. When EKS support is enabled the maximum sync period is 10 minutes. If you try to set --sync-period to greater than 10 minutes then an error will be raised.

EKS Console

To use the Amazon EKS Console to view workloads running in an EKS cluster created using the AWS provider (CAPA) you can do the following:

1. Create a new policy with the required IAM permissions for the console. This example can be used. For example, a policy called EKSViewNodesAndWorkloads.

2. Assign the policy created in step 1) to a IAM user or role for the users of your EKS cluster

3. Map the IAM user or role from step 2) to a Kubernetes user that has the RBAC permissions to view the Kubernetes resources. This needs to be done via the aws-auth configmap (used by aws-iam-authenticator) which is generated by the AWS provider. This mapping can be specified using in the AWSManagedControlPlane, for example:

kind: AWSManagedControlPlane
apiVersion: controlplane.cluster.x-k8s.io/v1beta1
metadata:
  name: "capi-managed-test-control-plane"
spec:
  region: "eu-west-2"
  sshKeyName: "capi-management"
  version: "v1.18.0"
  iamAuthenticatorConfig:
    mapRoles:
    - username: "kubernetes-admin"
      rolearn: "arn:aws:iam::1234567890:role/AdministratorAccess"
      groups:
      - "system:masters"

In the sample above the arn:aws:iam::1234567890:role/AdministratorAccess IAM role has the EKSViewNodesAndWorkloads policy attached (created in step 1.)

EKS Addons

EKS Addons can be used with EKS clusters created using Cluster API Provider AWS.

Addons are supported in EKS clusters using Kubernetes v1.18 or greater.

Installing addons

To install an addon you need to declare them by specifying the name, version and optionally how conflicts should be resolved in the AWSManagedControlPlane. For example:

kind: AWSManagedControlPlane
apiVersion: controlplane.cluster.x-k8s.io/v1beta1
metadata:
  name: "capi-managed-test-control-plane"
spec:
  region: "eu-west-2"
  sshKeyName: "capi-management"
  version: "v1.18.0"
  addons:
    - name: "vpc-cni"
      version: "v1.6.3-eksbuild.1"
      conflictResolution: "overwrite"

Additionally, there is a cluster flavor called eks-managedmachinepool-vpccni that you can use with clusterctl:

clusterctl generate cluster my-cluster --kubernetes-version v1.18.0 --flavor eks-managedmachinepool-vpccni > my-cluster.yaml

Updating Addons

To update the version of an addon you need to edit the AWSManagedControlPlane instance and update the version of the addon you want to update. Using the example from the previous section we would do:

...
  addons:
    - name: "vpc-cni"
      version: "v1.7.5-eksbuild.1"
      conflictResolution: "overwrite"
...

Deleting Addons

To delete an addon from a cluster you need to edit the AWSManagedControlPlane instance and remove the entry for the addon you want to delete.

Viewing installed addons

You can see what addons are installed on your EKS cluster by looking in the Status of the AWSManagedControlPlane instance.

Additionally you can run the following command:

clusterawsadm eks addons list-installed -n <<eksclustername>>

Viewing available addons

You can see what addons are available to your EKS cluster by running the following command:

clusterawsadm eks addons list-available -n <<eksclustername>>

Enabling Encryption

To enable encryption when creating a cluster you need to create a new KMS key that has an alias name starting with cluster-api-provider-aws-.

For example, arn:aws:kms:eu-north-1:12345678901:alias/cluster-api-provider-aws-key1.

You then need to specify this alias in the encryptionConfig of the AWSManagedControlPlane:

kind: AWSManagedControlPlane
apiVersion: controlplane.cluster.x-k8s.io/v1beta1
metadata:
  name: "capi-managed-test-control-plane"
spec:
  ...
  encryptionConfig:
    provider: "arn:aws:kms:eu-north-1:12345678901:alias/cluster-api-provider-aws-key1"
    resources:
    - "secrets"

Custom KMS Alias Prefix

If you would like to use a different alias prefix then you can use the kmsAliasPrefix in the optional configuration file for clusterawsadm:

clusterawsadm bootstrap iam create-stack --config custom-prefix.yaml

And the contents of the configuration file:

apiVersion: bootstrap.aws.infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSIAMConfiguration
spec:
  eks:
    enable: true
    kmsAliasPrefix: "my-prefix-*

EKS Cluster Upgrades

Control Plane Upgrade

Upgrading the Kubernetes version of the control plane is supported by the provider. To perform an upgrade you need to update the version in the spec of the AWSManagedControlPlane. Once the version has changed the provider will handle the upgrade for you.

You can only upgrade a EKS cluster by 1 minor version at a time. If you attempt to upgrade the version by more then 1 minor version the provider will ensure the upgrade is done in multiple steps of 1 minor version. For example upgrading from v1.15 to v1.17 would result in your cluster being upgraded v1.15 -> v1.16 first and then v1.16 to v1.17.

Consuming Existing AWS Infrastructure

Normally, Cluster API will create infrastructure on AWS when standing up a new workload cluster. However, it is possible to have Cluster API re-use existing AWS infrastructure instead of creating its own infrastructure. Follow the instructions below to configure Cluster API to consume existing AWS infrastructure.

Prerequisites

In order to have Cluster API consume existing AWS infrastructure, you will need to have already created the following resources:

• A VPC
• One or more private subnets (subnets that do not have a route to an Internet gateway)
• A NAT gateway for each private subnet, along with associated Elastic IP addresses (only needed if the nodes require access to the Internet, i.e. pulling public images)
  • A public subnet in the same Availability Zone (AZ) for each private subnet (this is required for NAT gateways to function properly)
• An Internet gateway for all public subnets (only required if the workload cluster is set to use an Internet facing load balancer or one or more NAT gateways exist in the VPC)
• Route table associations that provide connectivity to the Internet through a NAT gateway (for private subnets) or the Internet gateway (for public subnets)
• VPC endpoints for ec2, elasticloadbalancing, secretsmanager an autoscaling (if using MachinePools) when the private Subnets do not have a NAT gateway

You will need the ID of the VPC and subnet IDs that Cluster API should use. This information is available via the AWS Management Console or the AWS CLI.

Note that there is no need to create an Elastic Load Balancer (ELB), security groups, or EC2 instances; Cluster API will take care of these items.

If you want to use existing security groups, these can be specified and new ones will not be created.

Tagging AWS Resources

Cluster API itself does tag AWS resources it creates. The sigs.k8s.io/cluster-api-provider-aws/cluster/<cluster-name> (where <cluster-name> matches the metadata.name field of the Cluster object) tag, with a value of owned, tells Cluster API that it has ownership of the resource. In this case, Cluster API will modify and manage the lifecycle of the resource.

When consuming existing AWS infrastructure, the Cluster API AWS provider does not require any tags to be present. The absence of the tags on an AWS resource indicates to Cluster API that it should not modify the resource or attempt to manage the lifecycle of the resource.

However, the built-in Kubernetes AWS cloud provider does require certain tags in order to function properly. Specifically, all subnets where Kubernetes nodes reside should have the kubernetes.io/cluster/<cluster-name> tag present. Private subnets should also have the kubernetes.io/role/internal-elb tag with a value of 1, and public subnets should have the kubernetes.io/role/elb tag with a value of 1. These latter two tags help the cloud provider understand which subnets to use when creating load balancers.

Finally, if the controller manager isn’t started with the --configure-cloud-routes: "false" parameter, the route table(s) will also need the kubernetes.io/cluster/<cluster-name> tag. (This parameter can be added by customizing the KubeadmConfigSpec object of the KubeadmControlPlane object.)

Configuring the AWSCluster Specification

Specifying existing infrastructure for Cluster API to use takes place in the specification for the AWSCluster object. Specifically, you will need to add an entry with the VPC ID and the IDs of all applicable subnets into the network field. Here is an example:

For EC2

apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: AWSCluster

For EKS

apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: AWSManagedControlPlane

spec:
  network:
    vpc:
      id: vpc-0425c335226437144
    subnets:
    - id: subnet-0261219d564bb0dc5
    - id: subnet-0fdcccba78668e013

When you use kubectl apply to apply the Cluster and AWSCluster specifications to the management cluster, Cluster API will use the specified VPC ID and subnet IDs, and will not create a new VPC, new subnets, or other associated resources. It will, however, create a new ELB and new security groups.

Placing EC2 Instances in Specific AZs

To distribute EC2 instances across multiple AZs, you can add information to the Machine specification. This is optional and only necessary if control over AZ placement is desired.

To tell Cluster API that an EC2 instance should be placed in a particular AZ but allow Cluster API to select which subnet in that AZ can be used, add this to the Machine specification:

spec:
  failureDomain: "us-west-2a"

If using a MachineDeployment, specify AZ placement like so:

spec:
  template:
    spec:
      failureDomain: "us-west-2b"

Note that all replicas within a MachineDeployment will reside in the same AZ.

Placing EC2 Instances in Specific Subnets

To specify that an EC2 instance should be placed in a specific subnet, add this to the AWSMachine specification:

spec:
  subnet:
    id: subnet-0a3507a5ad2c5c8c3

When using MachineDeployments, users can control subnet selection by adding information to the AWSMachineTemplate associated with that MachineDeployment, like this:

spec:
  template:
    spec:
      subnet:
        id: subnet-0a3507a5ad2c5c8c3

Users may either specify failureDomain on the Machine or MachineDeployment objects, or users may explicitly specify subnet IDs on the AWSMachine or AWSMachineTemplate objects. If both are specified, the subnet ID is used and the failureDomain is ignored.

Security Groups

To use existing security groups for instances for a cluster, add this to the AWSCluster specification:

spec:
  network:
    securityGroupOverrides:
      bastion: sg-0350a3507a5ad2c5c8c3
      controlplane: sg-0350a3507a5ad2c5c8c3
      apiserver-lb: sg-0200a3507a5ad2c5c8c3
      node: sg-04e870a3507a5ad2c5c8c3
      lb: sg-00a3507a5ad2c5c8c3

Any additional security groups specified in an AWSMachineTemplate will be applied in addition to these overriden security groups.

To specify additional security groups for the control plane load balancer for a cluster, add this to the AWSCluster specification:

spec:
  controlPlaneLoadBalancer:
    AdditionalsecurityGroups:
    - sg-0200a3507a5ad2c5c8c3
    - ...

Caveats/Notes

• When both public and private subnets are available in an AZ, CAPI will choose the private subnet in the AZ over the public subnet for placing EC2 instances.
• If you configure CAPI to use existing infrastructure as outlined above, CAPI will not create an SSH bastion host. Combined with the previous bullet, this means you must make sure you have established some form of connectivity to the instances that CAPI will create.

Specifying the IAM Role to use for Management Components

Prerequisites

To be able to specify the IAM role that the management components should run as your cluster must be set up with the ability to assume IAM roles using one of the following solutions:

• IAM Roles for Service Accounts
• Kiam
• Kube2iam

Setting IAM Role

Set the AWS_CONTROLLER_IAM_ROLE environment variable to the ARN of the IAM role to use when performing the clustercrl init command.

For example:

export AWS_CONTROLLER_IAM_ROLE=arn:aws:iam::1234567890:role/capa-management-components
clusterctl init --infrastructure=aws

IAM Role Trust Policy

IAM Roles for Service Accounts

When creating the IAM role the following trust policy will need to be used with the AWS_ACCOUNT_ID, AWS_REGION and OIDC_PROVIDER_ID environment variables replaced.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::${AWS_ACCOUNT_ID}:oidc-provider/oidc.eks.${AWS_REGION}.amazonaws.com/id/${OIDC_PROVIDER_ID}"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "ForAnyValue:StringEquals": {
          "oidc.eks.${AWS_REGION}.amazonaws.com/id/${OIDC_PROVIDER_ID}:sub": [
            "system:serviceaccount:capa-system:capa-controller-manager",
            "system:serviceaccount:capi-system:capi-controller-manager",
            "system:serviceaccount:capa-eks-control-plane-system:capa-eks-control-plane-controller-manager",
            "system:serviceaccount:capa-eks-bootstrap-system:capa-eks-bootstrap-controller-manager",
          ]
        }
      }
    }
  ]
}

If you plan to use the controllers.cluster-api-provider-aws.sigs.k8s.io role created by clusterawsadm then you’ll need to add the following to your AWSIAMConfiguration:

apiVersion: bootstrap.aws.infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSIAMConfiguration
spec:
  clusterAPIControllers:
    disabled: false
    trustStatements:
    - Action:
      - "sts:AssumeRoleWithWebIdentity"
      Effect: "Allow"
      Principal:
        Federated:
        - "arn:aws:iam::${AWS_ACCOUNT_ID}:oidc-provider/oidc.eks.${AWS_REGION}.amazonaws.com/id/${OIDC_PROVIDER_ID}"
      Condition:
        "ForAnyValue:StringEquals":
          "oidc.eks.${AWS_REGION}.amazonaws.com/id/${OIDC_PROVIDER_ID}:sub":
            - system:serviceaccount:capa-system:capa-controller-manager
            - system:serviceaccount:capa-eks-control-plane-system:capa-eks-control-plane-controller-manager # Include if also using EKS

With this you can then set AWS_CONTROLLER_IAM_ROLE to arn:aws:iam::${AWS_ACCOUNT_ID}:role/controllers.cluster-api-provider-aws.sigs.k8s.io

Kiam / kube2iam

When creating the IAM role the you will need to give apply the kubernetes.io/cluster/${CLUSTER_NAME}/role": "enabled" tag to the role and use the following trust policy with the AWS_ACCOUNT_ID and CLUSTER_NAME environment variables correctly replaced.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    },
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::${AWS_ACCOUNT_ID}:role/${CLUSTER_NAME}.worker-node-role"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

If you plan to use the controllers.cluster-api-provider-aws.sigs.k8s.io role created by clusterawsadm then you’ll need to add the following to your AWSIAMConfiguration:

apiVersion: bootstrap.aws.infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSIAMConfiguration
spec:
  clusterAPIControllers:
    disabled: false
    trustStatements:
      - Action:
        - "sts:AssumeRole"
        Effect: "Allow"
        Principal:
          Service:
          - "ec2.amazonaws.com"
      - Action:
        - "sts:AssumeRole"
        Effect: "Allow"
        Principal:
          AWS:
          - "arn:aws:iam::${AWS_ACCOUNT_ID}:role/${CLUSTER_NAME}.worker-node-role"

With this you can then set AWS_CONTROLLER_IAM_ROLE to arn:aws:iam::${AWS_ACCOUNT_ID}:role/controllers.cluster-api-provider-aws.sigs.k8s.io

Multi-AZ Control Plane

Overview

By default, the control plane of a workload cluster created by CAPA will span multiple availability zones (AZs) (also referred to as “failure domains”) when using multiple control plane nodes. This is because CAPA will, by default, create public and private subnets in all the AZs of a region (up to a maximum of 3 AZs by default). If a region has more than 3 AZs then CAPA will pick 3 AZs to use.

Configuring CAPA to Use Specific AZs

To explicitly instruct CAPA to create resources in specific AZs (and not by random), users can add a network object to the AWSCluster specification. Here is an example network that creates resources across three AZs in the “us-west-2” region:

spec:
  network:
    vpc:
      cidrBlock: 10.50.0.0/16
    subnets:
    - availabilityZone: us-west-2a
      cidrBlock: 10.50.0.0/20
      isPublic: true
    - availabilityZone: us-west-2a
      cidrBlock: 10.50.16.0/20
    - availabilityZone: us-west-2b
      cidrBlock: 10.50.32.0/20
      isPublic: true
    - availabilityZone: us-west-2b
      cidrBlock: 10.50.48.0/20
    - availabilityZone: us-west-2c
      cidrBlock: 10.50.64.0/20
      isPublic: true
    - availabilityZone: us-west-2c
      cidrBlock: 10.50.80.0/20

Specifying the CIDR block alone for the VPC is not enough; users must also supply a list of subnets that provides the desired AZ, the CIDR for the subnet, and whether the subnet is public (has a route to an Internet gateway) or is private (does not have a route to an Internet gateway).

Note that CAPA insists that there must be a public subnet (and associated Internet gateway), even if no public load balancer is requested for the control plane. Therefore, for every AZ where a control plane node should be placed, the network object must define both a public and private subnet.

Once CAPA is provided with a network that spans multiple AZs, the KubeadmControlPlane controller will automatically distribute control plane nodes across multiple AZs. No further configuration from the user is required.

Note: this method can also be used if you do not want to split your EC2 instance across multiple AZs.

Changing AZ defaults

When creating default subnets by default a maximum of 3 AZs will be used. If you are creating a cluster in a region that has more than 3 AZs then 3 AZs will be picked based on alphabetical from that region.

If this default behavior for maximum number of AZs and ordered selection method doesn’t suit your requirements you can use the following to change the behaviour:

• availabilityZoneUsageLimit - specifies the maximum number of availability zones (AZ) that should be used in a region when automatically creating subnets.
• availabilityZoneSelection - specifies how AZs should be selected if there are more AZs in a region than specified by availabilityZoneUsageLimit. There are 2 selection schemes:
  • Ordered - selects based on alphabetical order
  • Random - selects AZs randomly in a region

For example if you wanted have a maximum of 2 AZs using a random selection scheme:

spec:
  network:
    vpc:
      availabilityZoneUsageLimit: 2
      availabilityZoneSelection: Random

Caveats

Deploying control plane nodes across multiple AZs is not a panacea to cure all availability concerns. The sizing and overall utilization of the cluster will greatly affect the behavior of the cluster and the workloads hosted there in the event of an AZ failure. Careful planning is needed to maximize the availability of the cluster even in the face of an AZ failure. There are also other considerations, like cross-AZ traffic charges, that should be taken into account.

External AWS cloud provider with AWS EBS CSI driver

Overview

From Kubernetes 1.21 onwards, the support for its in-tree AWS cloud provider and the EBS CSI driver is removed, hence there is a need to use out-of-tree cloud provider (Cloud Controller Manager - CCM) and a CSI driver in CAPA. For details, see Status of project and documentation of Cloud provider AWS

Using external cloud provider and EBS CSI driver in AWS workloads

Once Management cluster is ready, install external CCM and EBS CSI driver onto the CAPA workload cluster either manually or using ClusterResourceSets (CRS). To install them with CRS, create a CRS resource on the management cluster with labels, for example csi: external and ccm: external labels. Then, when creating Cluster objects for workload clusters that should have this CSR applied, create them with matching labels csi: external and ccm: external for CSI and CCM, respectively.

Manifests for installing the AWS CCM and the AWS EBS CSI driver are available from their respective GitHub repositories (see here for the AWS CCM and here for the AWS EBS CSI driver).

An example of a workload cluster manifest with labels assigned for matching to a CRS can be found here.

Verifying dynamically provisioned volumes with CSI driver

Once you have the cluster with external CCM and CSI controller running successfully, you can test the CSI driver functioning with following steps after switching to workload cluster:

1. Create a service (say,nginx)

apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
  namespace: default
spec:
  clusterIP: None
  ports:
    - name: nginx-web
      port: 80
  selector:
    app: nginx

2. Create a storageclass and statefulset for the service created above with the persistent volume assigned to the storageclass:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: aws-ebs-volumes
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
  csi.storage.k8s.io/fstype: xfs
  type: io1
  iopsPerGB: "100"
allowedTopologies:
  - matchLabelExpressions:
      - key: topology.ebs.csi.aws.com/zone
        values:
          - us-east-1a
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: nginx-statefulset
spec:
  serviceName: "nginx-svc"
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: k8s.gcr.io/nginx-slim:0.8
          ports:
            - name: nginx-web
              containerPort: 80
          volumeMounts:
            - name: nginx-volumes
              mountPath: /usr/share/nginx/html
      volumes:
        - name: nginx-volumes
          persistentVolumeClaim:
            claimName: nginx-volumes
  volumeClaimTemplates:
    - metadata:
        name: nginx-volumes
      spec:
        storageClassName: "aws-ebs-volumes"
        accessModes: [ "ReadWriteOnce" ]
        resources:
          requests:
            storage: 4Gi

3. Once you apply the above manifest, the EBS volumes will be created and attached to the worker nodes.

IMPORTANT WARNING: The CRDs from the AWS EBS CSI driver and AWS out-of-tree cloud provider gives issue while installing the respective controllers on the AWS Cluster, it doesn’t allow statefulsets to create the volume on existing EC2 instance. We need the CSI controller deployment and CCM pinned to the control plane which has right permissions to create, attach and mount the volumes to EC2 instances. To achieve this, you should add the node affinity rules to the CSI driver controller deployment and CCM DaemonSet manifests.

tolerations:
- key: node-role.kubernetes.io/master
  effect: NoSchedule
- effect: NoSchedule
  key: node-role.kubernetes.io/control-plane 
affinity:
  nodeAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
    nodeSelectorTerms:
      - matchExpressions:
          - key: node-role.kubernetes.io/control-plane
            operator: Exists
      - matchExpressions:
          - key: node-role.kubernetes.io/master
            operator: Exists

Restricting Cluster API to certain namespaces

Cluster-api-provider-aws controllers by default, reconcile cluster-api objects across all namespaces in the cluster. However, it is possible to restrict reconciliation to a single namespace and this document tells you how.

Contents

• Use cases
• Configuring cluster-api-provider-aws controllers

Use cases

• Grouping clusters into a namespace based on the AWS account will allow managing clusters across multiple AWS accounts. This will require each cluster-api-provider-aws controller to have credentials to their respective AWS accounts. These credentials can be created as kubernetes secret and be mounted in the pod at /home/.aws or as environment variables.
• Grouping clusters into a namespace based on their environment, (test, qualification, canary, production) will allow a phased rolling out of cluster-api-provider-aws releases.
• Grouping clusters into a namespace based on the infrastructure provider will allow running multiple cluster-api provider implementations side-by-side and manage clusters across infrastructure providers.

Configuring cluster-api-provider-aws controllers

• Create the namespace that cluster-api-provider-aws controller will watch for cluster-api objects

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Namespace
metadata:
  name: my-pet-clusters #edit if necessary
EOF

• Deploy/edit aws-provider-controller-manager controller statefulset

Specifically, edit the container spec for cluster-api-aws-controller, in the aws-provider-controller-manager statefulset, to pass a value to the namespace CLI flag.

        - -namespace=my-pet-clusters # edit this if necessary

Once the aws-provider-controller-manager-0 pod restarts, cluster-api-provider-aws controllers will only reconcile the cluster-api objects in the my-pet-clusters namespace.

For v0.3.x please refer to https://github.com/kubernetes-sigs/cluster-api-provider-aws/blob/release-0.3/docs/roleassumption.md

Creating clusters using cross account role assumption using KIAM

This document outlines the list of steps to create the target cluster via cross account role assumption using KIAM. KIAM lets the controller pod(s) to assume an AWS role that enables them create AWS resources necessary to create an operational cluster. This way we wouldn’t have to mount any AWS credentials or load environment variables to supply AWS credentials to the CAPA controller. This is automatically taken care by the KIAM components. Note: If you dont want to use KIAM and rather want to mount the credentials as secrets, you may still achieve cross account role assumption by using multiple profiles.

Glossary

• Management cluster - The cluster that runs in AWS and is used to create target clusters in different AWS accounts
• Target account - The account where the target cluster is created
• Source account - The AWS account where the CAPA controllers for management cluster runs.

Goals

1. The CAPA controllers are running in an AWS account and you want to create the target cluster in another AWS account.
2. This assumes that you start with no existing clusters.

High level steps

1. Creating a management cluster in AWS - This can be done by running the phases in clusterctl
   • Uses the existing provider components yaml
2. Setting up cross account IAM roles
3. Deploying the KIAM server/agent
4. Create the target cluster (through KIAM)
   • Uses different provider components with no secrets and annotation to indicate the IAM Role to assume.

1. Creating the management cluster in AWS

Using clusterctl command we can create a new cluster in AWS which in turn will act as the management cluster to create the target cluster(in a different AWS account. This can be achieved by using the phases in clusterctl to perform all the steps except the pivoting. This will provide us with a bare-bones functioning cluster that we can use as a management cluster. To begin with follow the steps in this getting started guide to setup the environment except for creating the actual cluster. Instead follow the steps below to create the cluster.

create a new cluster using kind for bootstrapping purpose by running:

kind create cluster --name <CLUSTER_NAME>

and get its kube config path by running

export KIND_KUBECONFIG=`kind get kubeconfig-path`

Use the following commands to create new management cluster in AWS.

clusterctl alpha phases apply-cluster-api-components --provider-components examples/out/provider-components.yaml \
--kubeconfig $KIND_KUBECONFIG

clusterctl alpha phases apply-cluster --cluster examples/out/cluster.yaml --kubeconfig $KIND_KUBECONFIG

We only need to create the control plane on the cluster running in AWS source account. Since the example includes definition for a worker node, you may delete it.

clusterctl alpha phases apply-machines --machines examples/out/machines.yaml --kubeconfig $KIND_KUBECONFIG

clusterctl alpha phases get-kubeconfig --provider aws --cluster-name <CLUSTER_NAME> --kubeconfig $KIND_KUBECONFIG

export AWS_KUBECONFIG=$PWD/kubeconfig

kubectl apply -f examples/out/addons.yaml --kubeconfig $AWS_KUBECONFIG

Verify that all the pods in the kube-system namespace are running smoothly. Also you may remove the additional node in the machines example yaml since we are only interested in running the controllers that runs in control plane node (although its not required to make any changes there). You can destroy your local kind cluster by running

kind delete cluster --name <CLUSTER_NAME>

2. Setting up cross account roles

In this step we will create new roles/policy in across 2 different AWS accounts. Let us start by creating the roles in the account where the AWS controller runs. Following the directions posted in KIAM repo create a “kiam_server” role in AWS that only has a single managed policy with a single permission “sts:AssumeRole”. Also add a trust policy on the “kiam_server” role to include the role attached to the Control plane instance as a trusted entity. This looks something like this:

In “kiam_server” role (Source AWS account):

{
 "Version": "2012-10-17",
 "Statement": [
   {
     "Effect": "Allow",
     "Principal": {
       "AWS": "arn:aws:iam::<AWS_ACCOUNT_NUMBER>:role/control-plane.cluster-api-provider-aws.sigs.k8s.io"
     },
     "Action": "sts:AssumeRole"
   }
 ]
}

Next we must establish a link between this “kiam_server” role on source AWS account and the role on target AWS account that has the permissions to create new cluster. Begin by running the clusterawsadm cli to create a new stack on the target account where the target cluster is created. Make sure you use the credentials for target AWS account before creating the stack.

clusterawsadm alpha bootstrap create-stack

Then sign-in to the target AWS account to establish the link as mentioned above. Create a new Role with the permission policy set to “controllers.cluster-api-provider-aws.sigs.k8s.io”. Lets name this role “cluster-api” for future reference. Add a new trust relationship to include the “kiam_server” role from the source account as trusted entity. This is shown below:

In “controllers.cluster-api-provider-aws.sigs.k8s.io” role(target AWS account)

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

3. Deploying the KIAM server & agent

By now, your target cluster must be up & running. Make sure your KUBECONFIG pointing to the cluster in the target account.

Create new secrets using the steps outlined here Apply the manifest shown below: Make sure you update the argument to include your source AWS account “--assume-role-arn=arn:aws:iam::<SOURCE_AWS_ACCOUNT>:role/kiam_server” server.yaml

---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  namespace: kube-system
  name: kiam-server
spec:
  template:
    metadata:
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "9620"
      labels:
        app: kiam
        role: server
    spec:
      serviceAccountName: kiam-server
      nodeSelector:
        node-role.kubernetes.io/master: ""
      tolerations:
      - operator: "Exists"
      volumes:
        - name: ssl-certs
          hostPath:
            # for AWS linux or RHEL distros
            # path: /etc/pki/ca-trust/extracted/pem/
            path: /etc/ssl/certs/
        - name: tls
          secret:
            secretName: kiam-server-tls
      hostNetwork: true
      containers:
        - name: kiam
          image: quay.io/uswitch/kiam:v3.2
          imagePullPolicy: Always
          command:
            - /kiam
          args:
            - server
            - --json-log
            - --level=warn
            - --bind=0.0.0.0:443
            - --cert=/etc/kiam/tls/server.pem
            - --key=/etc/kiam/tls/server-key.pem
            - --ca=/etc/kiam/tls/ca.pem
            - --role-base-arn-autodetect
            - --assume-role-arn=arn:aws:iam::<SOURCE_AWS_ACCOUNT>:role/kiam_server
            - --sync=1m
            - --prometheus-listen-addr=0.0.0.0:9620
            - --prometheus-sync-interval=5s
          volumeMounts:
            - mountPath: /etc/ssl/certs
              name: ssl-certs
            - mountPath: /etc/kiam/tls
              name: tls
          livenessProbe:
            exec:
              command:
              - /kiam
              - health
              - --cert=/etc/kiam/tls/server.pem
              - --key=/etc/kiam/tls/server-key.pem
              - --ca=/etc/kiam/tls/ca.pem
              - --server-address=127.0.0.1:443
              - --gateway-timeout-creation=1s
              - --timeout=5s
            initialDelaySeconds: 10
            periodSeconds: 10
            timeoutSeconds: 10
          readinessProbe:
            exec:
              command:
              - /kiam
              - health
              - --cert=/etc/kiam/tls/server.pem
              - --key=/etc/kiam/tls/server-key.pem
              - --ca=/etc/kiam/tls/ca.pem
              - --server-address=127.0.0.1:443
              - --gateway-timeout-creation=1s
              - --timeout=5s
            initialDelaySeconds: 3
            periodSeconds: 10
            timeoutSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: kiam-server
  namespace: kube-system
spec:
  clusterIP: None
  selector:
    app: kiam
    role: server
  ports:
  - name: grpclb
    port: 443
    targetPort: 443
    protocol: TCP

agent.yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
  namespace: kube-system
  name: kiam-agent
spec:
  template:
    metadata:
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "9620"
      labels:
        app: kiam
        role: agent
    spec:
      hostNetwork: true
      dnsPolicy: ClusterFirstWithHostNet
      tolerations:
        - operator: "Exists"
      volumes:
        - name: ssl-certs
          hostPath:
            # for AWS linux or RHEL distros
            #path: /etc/pki/ca-trust/extracted/pem/
            path: /etc/ssl/certs/
        - name: tls
          secret:
            secretName: kiam-agent-tls
        - name: xtables
          hostPath:
            path: /run/xtables.lock
            type: FileOrCreate
      containers:
        - name: kiam
          securityContext:
            capabilities:
              add: ["NET_ADMIN"]
          image: quay.io/uswitch/kiam:v3.2
          imagePullPolicy: Always
          command:
            - /kiam
          args:
            - agent
            - --iptables
            - --host-interface=cali+
            - --json-log
            - --port=8181
            - --cert=/etc/kiam/tls/agent.pem
            - --key=/etc/kiam/tls/agent-key.pem
            - --ca=/etc/kiam/tls/ca.pem
            - --server-address=kiam-server:443
            - --prometheus-listen-addr=0.0.0.0:9620
            - --prometheus-sync-interval=5s
            - --gateway-timeout-creation=1s
          env:
            - name: HOST_IP
              valueFrom:
                fieldRef:
                  fieldPath: status.podIP
          volumeMounts:
            - mountPath: /etc/ssl/certs
              name: ssl-certs
            - mountPath: /etc/kiam/tls
              name: tls
            - mountPath: /var/run/xtables.lock
              name: xtables
          livenessProbe:
            httpGet:
              path: /ping
              port: 8181
            initialDelaySeconds: 3
            periodSeconds: 3

server-rbac.yaml

---
kind: ServiceAccount
apiVersion: v1
metadata:
  name: kiam-server
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: kiam-read
rules:
- apiGroups:
  - ""
  resources:
  - namespaces
  - pods
  verbs:
  - watch
  - get
  - list
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kiam-read
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: kiam-read
subjects:
- kind: ServiceAccount
  name: kiam-server
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: kiam-write
rules:
- apiGroups:
  - ""
  resources:
  - events
  verbs:
  - create
  - patch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kiam-write
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: kiam-write
subjects:
- kind: ServiceAccount
  name: kiam-server
  namespace: kube-system

After deploying the above components make sure that the kiam_server and kiam_agent pods are up and running.

4. Create the target cluster

Make sure you create copy of the “aws/out” directory called “out2”. To create the target cluster we must update the provider_components.yaml generated in the out2 directory as shown below (to be run from the repository root directory):

cp examples/out examples/out2
vi examples/out2/provider-components.yaml

1. Remove the credentials secret added at the bottom of the provider_components.yaml and do not mount the secret
2. Add the following annotation to the template of aws-provider-controller-manager stateful set to specify the new role that was created in target account.

      annotations:
        iam.amazonaws.com/role: arn:aws:iam::<TARGET_AWS_ACCOUNT>:role/cluster-api

3. Also add this below annotation to the “aws-provider-system” namespace

  annotations:
    iam.amazonaws.com/permitted: ".*"

Create a new cluster using the steps similar to the one used to create the source cluster. They are as follows:

export SOURCE_KUBECONFIG=<PATH_TO_SOURCE_CLUSTER_KUBECONFIG>

clusterctl alpha phases apply-cluster-api-components --provider-components examples/out2/provider-components.yaml \
--kubeconfig $SOURCE_KUBECONFIG

kubectl -f apply examples/out2/cluster.yaml --kubeconfig $SOURCE_KUBECONFIG

kubectl apply -f examples/out2/machines.yaml --kubeconfig $SOURCE_KUBECONFIG

clusterctl alpha phases get-kubeconfig --provider aws --cluster-name <TARGET_CLUSTER_NAME> --kubeconfig $SOURCE_KUBECONFIG
export KUBECONFIG=$PWD/kubeconfig

kubectl apply -f examples/out2/addons.yaml

This creates the new cluster in the target AWS account.

Userdata Privacy

Cluster API Provider AWS bootstraps EC2 instances to create and join Kubernetes clusters using instance user data. Because Kubernetes clusters are secured using TLS using multiple Certificate Authorities, these are generated by Cluster API and injected into the user data. It is important to note that without the configuring of host firewalls, processes can retrieve instance userdata from http://169.254.169.254/latest/api/token

Requirements

• An AMI that includes the AWS CLI
• AMIs using CloudInit
• A working /bin/bash shell
• LFS directory layout (i.e. /etc exists and is readable by CloudInit)

Listed AMIs on 1.16 and up should include the AWS CLI.

How Cluster API secures TLS secrets

Since v0.5.x, Cluster API Provider AWS has used AWS Secrets Manager as a limited-time secret store, storing the userdata using KMS encryption at rest in AWS. The EC2 IMDS userdata will contain a boot script to download the encrypted userdata secret using instance profile permissions, then immediately delete it from AWS Secrets Manager, and then execute it.

To avoid guessing keys in the AWS Secrets Manager key-value store and to prevent collisions, the key is an encoding the Kubernetes namespace, cluster name and instance name, with a random string appended, providing ~256-bits of entropy.

Cluster API Provider AWS also stores the secret ARN in the AWSMachine spec, and will delete the secret if it isn’t already deleted and the machine has registered successfully against the workload cluster API server as a node. Cluster API Provider AWS will also attempt deletion of the secret if the AWSMachine is otherwise deleted or the EC2 instance is terminated or failed.

This method is only compatible with operating systems and distributions using cloud-init. If you are using a different bootstrap process, you will need to co-ordinate this externally and set the following in the specification of the AWSMachine types to disable the use of a cloud-init boothook:

cloudInit:
  insecureSkipSecretsManager: true

Troubleshooting

Script errors

cloud-init does not print boothook script errors to the systemd journal. Logs for the script, if it errored can be found in /var/log/cloud-init-output.log

Warning messages

Because cloud-init will attempt to read the final file at start, cloud-init will always print a /etc/secret-userdata.txt cannot be found message. This can be safely ignored.

Secrets manager console

The AWS secrets manager console should show secrets being created and deleted, with a lifetime of around a minute. No plaintext secret data will appear in the console as Cluster API Provider AWS stores the userdata as fragments of a gzipped data stream.

Troubleshooting

Resources aren’t being created

TODO

Target cluster’s control plane machine is up but target cluster’s apiserver not working as expected

If aws-provider-controller-manager-0 logs did not help, you might want to look into cloud-init logs, /var/log/cloud-init-output.log, on the controller host. Verifying kubelet status and logs may also provide hints:

journalctl -u kubelet.service
systemctl status kubelet

For reaching controller host from your local machine:

 ssh -i <private-key> -o "ProxyCommand ssh -W %h:%p -i <private-key> ubuntu@<bastion-IP>" ubuntu@<controller-host-IP>

private-key is the private key from the key-pair discussed in the ssh key pair section above.

kubelet on the control plane host failing with error: NoCredentialProviders

failed to run Kubelet: could not init cloud provider "aws": error finding instance i-0c276f2a1f1c617b2: "error listing AWS instances: \"NoCredentialProviders: no valid providers in chain. Deprecated.\\n\\tFor verbose messaging see aws.Config.CredentialsChainVerboseErrors\""

This error can occur if CloudFormation stack is not created properly and IAM instance profile is missing appropriate roles. Run following command to inspect IAM instance profile:

$ aws iam get-instance-profile --instance-profile-name control-plane.cluster-api-provider-aws.sigs.k8s.io --output json
{
    "InstanceProfile": {
        "InstanceProfileId": "AIPAJQABLZS4A3QDU576Q",
        "Roles": [
            {
                "AssumeRolePolicyDocument": {
                    "Version": "2012-10-17",
                    "Statement": [
                        {
                            "Action": "sts:AssumeRole",
                            "Effect": "Allow",
                            "Principal": {
                                "Service": "ec2.amazonaws.com"
                            }
                        }
                    ]
                },
                "RoleId": "AROAJQABLZS4A3QDU576Q",
                "CreateDate": "2019-05-13T16:45:12Z",
                "RoleName": "control-plane.cluster-api-provider-aws.sigs.k8s.io",
                "Path": "/",
                "Arn": "arn:aws:iam::123456789012:role/control-plane.cluster-api-provider-aws.sigs.k8s.io"
            }
        ],
        "CreateDate": "2019-05-13T16:45:28Z",
        "InstanceProfileName": "control-plane.cluster-api-provider-aws.sigs.k8s.io",
        "Path": "/",
        "Arn": "arn:aws:iam::123456789012:instance-profile/control-plane.cluster-api-provider-aws.sigs.k8s.io"
    }
}

If instance profile does not look as expected, you may try recreating the CloudFormation stack using clusterawsadm as explained in the above sections.

IAM Permissions

Required to use clusterawasadm to provision IAM roles via CloudFormation

If using clusterawsadm to automate deployment of IAM roles via CloudFormation, you must have IAM administrative access as clusterawsadm will provision IAM roles and policies.

Required by Cluster API Provider AWS controllers

The Cluster API Provider AWS controller requires permissions to use EC2, ELB Autoscaling and optionally EKS. If provisioning IAM roles using clusterawsadm, these will be set up as the controllers.cluster-api-provider-aws.sigs.k8s.io IAM Policy, and attached to the controllers.cluster-api-provider-aws.sigs.k8s.io and control-plane.cluster-api-provider-aws.sigs.k8s.io IAM roles.

EC2 Provisioned Kubernetes Clusters

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:AllocateAddress",
        "ec2:AssociateRouteTable",
        "ec2:AttachInternetGateway",
        "ec2:AuthorizeSecurityGroupIngress",
        "ec2:CreateInternetGateway",
        "ec2:CreateNatGateway",
        "ec2:CreateRoute",
        "ec2:CreateRouteTable",
        "ec2:CreateSecurityGroup",
        "ec2:CreateSubnet",
        "ec2:CreateTags",
        "ec2:CreateVpc",
        "ec2:ModifyVpcAttribute",
        "ec2:DeleteInternetGateway",
        "ec2:DeleteNatGateway",
        "ec2:DeleteRouteTable",
        "ec2:DeleteSecurityGroup",
        "ec2:DeleteSubnet",
        "ec2:DeleteTags",
        "ec2:DeleteVpc",
        "ec2:DescribeAccountAttributes",
        "ec2:DescribeAddresses",
        "ec2:DescribeAvailabilityZones",
        "ec2:DescribeInstances",
        "ec2:DescribeInternetGateways",
        "ec2:DescribeImages",
        "ec2:DescribeNatGateways",
        "ec2:DescribeNetworkInterfaces",
        "ec2:DescribeNetworkInterfaceAttribute",
        "ec2:DescribeRouteTables",
        "ec2:DescribeSecurityGroups",
        "ec2:DescribeSubnets",
        "ec2:DescribeVpcs",
        "ec2:DescribeVpcAttribute",
        "ec2:DescribeVolumes",
        "ec2:DetachInternetGateway",
        "ec2:DisassociateRouteTable",
        "ec2:DisassociateAddress",
        "ec2:ModifyInstanceAttribute",
        "ec2:ModifyNetworkInterfaceAttribute",
        "ec2:ModifySubnetAttribute",
        "ec2:ReleaseAddress",
        "ec2:RevokeSecurityGroupIngress",
        "ec2:RunInstances",
        "ec2:TerminateInstances",
        "tag:GetResources",
        "elasticloadbalancing:AddTags",
        "elasticloadbalancing:CreateLoadBalancer",
        "elasticloadbalancing:ConfigureHealthCheck",
        "elasticloadbalancing:DeleteLoadBalancer",
        "elasticloadbalancing:DescribeLoadBalancers",
        "elasticloadbalancing:DescribeLoadBalancerAttributes",
        "elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
        "elasticloadbalancing:DescribeTags",
        "elasticloadbalancing:ModifyLoadBalancerAttributes",
        "elasticloadbalancing:RegisterInstancesWithLoadBalancer",
        "elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
        "elasticloadbalancing:RemoveTags",
        "autoscaling:DescribeAutoScalingGroups",
        "autoscaling:DescribeInstanceRefreshes",
        "ec2:CreateLaunchTemplate",
        "ec2:CreateLaunchTemplateVersion",
        "ec2:DescribeLaunchTemplates",
        "ec2:DescribeLaunchTemplateVersions",
        "ec2:DeleteLaunchTemplate",
        "ec2:DeleteLaunchTemplateVersions",
        "ec2:DescribeKeyPairs"
      ],
      "Resource": [
        "*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "autoscaling:CreateAutoScalingGroup",
        "autoscaling:UpdateAutoScalingGroup",
        "autoscaling:CreateOrUpdateTags",
        "autoscaling:StartInstanceRefresh",
        "autoscaling:DeleteAutoScalingGroup",
        "autoscaling:DeleteTags"
      ],
      "Resource": [
        "arn:*:autoscaling:*:*:autoScalingGroup:*:autoScalingGroupName/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:CreateServiceLinkedRole"
      ],
      "Resource": [
        "arn:*:iam::*:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling"
      ],
      "Condition": {
        "StringLike": {
          "iam:AWSServiceName": "autoscaling.amazonaws.com"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:CreateServiceLinkedRole"
      ],
      "Resource": [
        "arn:*:iam::*:role/aws-service-role/elasticloadbalancing.amazonaws.com/AWSServiceRoleForElasticLoadBalancing"
      ],
      "Condition": {
        "StringLike": {
          "iam:AWSServiceName": "elasticloadbalancing.amazonaws.com"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:CreateServiceLinkedRole"
      ],
      "Resource": [
        "arn:*:iam::*:role/aws-service-role/spot.amazonaws.com/AWSServiceRoleForEC2Spot"
      ],
      "Condition": {
        "StringLike": {
          "iam:AWSServiceName": "spot.amazonaws.com"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:PassRole"
      ],
      "Resource": [
        "arn:*:iam::*:role/*.cluster-api-provider-aws.sigs.k8s.io"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "secretsmanager:CreateSecret",
        "secretsmanager:DeleteSecret",
        "secretsmanager:TagResource"
      ],
      "Resource": [
        "arn:*:secretsmanager:*:*:secret:aws.cluster.x-k8s.io/*"
      ]
    }
  ]
}

With EKS Support

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:AllocateAddress",
        "ec2:AssociateRouteTable",
        "ec2:AttachInternetGateway",
        "ec2:AuthorizeSecurityGroupIngress",
        "ec2:CreateInternetGateway",
        "ec2:CreateNatGateway",
        "ec2:CreateRoute",
        "ec2:CreateRouteTable",
        "ec2:CreateSecurityGroup",
        "ec2:CreateSubnet",
        "ec2:CreateTags",
        "ec2:CreateVpc",
        "ec2:ModifyVpcAttribute",
        "ec2:DeleteInternetGateway",
        "ec2:DeleteNatGateway",
        "ec2:DeleteRouteTable",
        "ec2:DeleteSecurityGroup",
        "ec2:DeleteSubnet",
        "ec2:DeleteTags",
        "ec2:DeleteVpc",
        "ec2:DescribeAccountAttributes",
        "ec2:DescribeAddresses",
        "ec2:DescribeAvailabilityZones",
        "ec2:DescribeInstances",
        "ec2:DescribeInternetGateways",
        "ec2:DescribeImages",
        "ec2:DescribeNatGateways",
        "ec2:DescribeNetworkInterfaces",
        "ec2:DescribeNetworkInterfaceAttribute",
        "ec2:DescribeRouteTables",
        "ec2:DescribeSecurityGroups",
        "ec2:DescribeSubnets",
        "ec2:DescribeVpcs",
        "ec2:DescribeVpcAttribute",
        "ec2:DescribeVolumes",
        "ec2:DetachInternetGateway",
        "ec2:DisassociateRouteTable",
        "ec2:DisassociateAddress",
        "ec2:ModifyInstanceAttribute",
        "ec2:ModifyNetworkInterfaceAttribute",
        "ec2:ModifySubnetAttribute",
        "ec2:ReleaseAddress",
        "ec2:RevokeSecurityGroupIngress",
        "ec2:RunInstances",
        "ec2:TerminateInstances",
        "tag:GetResources",
        "elasticloadbalancing:AddTags",
        "elasticloadbalancing:CreateLoadBalancer",
        "elasticloadbalancing:ConfigureHealthCheck",
        "elasticloadbalancing:DeleteLoadBalancer",
        "elasticloadbalancing:DescribeLoadBalancers",
        "elasticloadbalancing:DescribeLoadBalancerAttributes",
        "elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
        "elasticloadbalancing:DescribeTags",
        "elasticloadbalancing:ModifyLoadBalancerAttributes",
        "elasticloadbalancing:RegisterInstancesWithLoadBalancer",
        "elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
        "elasticloadbalancing:RemoveTags",
        "autoscaling:DescribeAutoScalingGroups",
        "autoscaling:DescribeInstanceRefreshes",
        "ec2:CreateLaunchTemplate",
        "ec2:CreateLaunchTemplateVersion",
        "ec2:DescribeLaunchTemplates",
        "ec2:DescribeLaunchTemplateVersions",
        "ec2:DeleteLaunchTemplate",
        "ec2:DeleteLaunchTemplateVersions",
        "ec2:DescribeKeyPairs"
      ],
      "Resource": [
        "*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "autoscaling:CreateAutoScalingGroup",
        "autoscaling:UpdateAutoScalingGroup",
        "autoscaling:CreateOrUpdateTags",
        "autoscaling:StartInstanceRefresh",
        "autoscaling:DeleteAutoScalingGroup",
        "autoscaling:DeleteTags"
      ],
      "Resource": [
        "arn:*:autoscaling:*:*:autoScalingGroup:*:autoScalingGroupName/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:CreateServiceLinkedRole"
      ],
      "Resource": [
        "arn:*:iam::*:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling"
      ],
      "Condition": {
        "StringLike": {
          "iam:AWSServiceName": "autoscaling.amazonaws.com"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:CreateServiceLinkedRole"
      ],
      "Resource": [
        "arn:*:iam::*:role/aws-service-role/elasticloadbalancing.amazonaws.com/AWSServiceRoleForElasticLoadBalancing"
      ],
      "Condition": {
        "StringLike": {
          "iam:AWSServiceName": "elasticloadbalancing.amazonaws.com"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:CreateServiceLinkedRole"
      ],
      "Resource": [
        "arn:*:iam::*:role/aws-service-role/spot.amazonaws.com/AWSServiceRoleForEC2Spot"
      ],
      "Condition": {
        "StringLike": {
          "iam:AWSServiceName": "spot.amazonaws.com"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:PassRole"
      ],
      "Resource": [
        "arn:*:iam::*:role/*.cluster-api-provider-aws.sigs.k8s.io"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "secretsmanager:CreateSecret",
        "secretsmanager:DeleteSecret",
        "secretsmanager:TagResource"
      ],
      "Resource": [
        "arn:*:secretsmanager:*:*:secret:aws.cluster.x-k8s.io/*"
      ]
    }
  ]
}

Required by the Kubernetes AWS Cloud Provider

These permissions are used by the Kubernetes AWS Cloud Provider. If you are running with the in-tree cloud provider, this will typically be used by the controller-manager pod in the kube-system namespace.

If provisioning IAM roles using clusterawsadm, these will be set up as the control-plane.cluster-api-provider-aws.sigs.k8s.io IAM Policy, and attached to the control-plane.cluster-api-provider-aws.sigs.k8s.io IAM role.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "autoscaling:DescribeAutoScalingGroups",
        "autoscaling:DescribeLaunchConfigurations",
        "autoscaling:DescribeTags",
        "ec2:DescribeInstances",
        "ec2:DescribeImages",
        "ec2:DescribeRegions",
        "ec2:DescribeRouteTables",
        "ec2:DescribeSecurityGroups",
        "ec2:DescribeSubnets",
        "ec2:DescribeVolumes",
        "ec2:CreateSecurityGroup",
        "ec2:CreateTags",
        "ec2:CreateVolume",
        "ec2:ModifyInstanceAttribute",
        "ec2:ModifyVolume",
        "ec2:AttachVolume",
        "ec2:AuthorizeSecurityGroupIngress",
        "ec2:CreateRoute",
        "ec2:DeleteRoute",
        "ec2:DeleteSecurityGroup",
        "ec2:DeleteVolume",
        "ec2:DetachVolume",
        "ec2:RevokeSecurityGroupIngress",
        "ec2:DescribeVpcs",
        "elasticloadbalancing:AddTags",
        "elasticloadbalancing:AttachLoadBalancerToSubnets",
        "elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
        "elasticloadbalancing:CreateLoadBalancer",
        "elasticloadbalancing:CreateLoadBalancerPolicy",
        "elasticloadbalancing:CreateLoadBalancerListeners",
        "elasticloadbalancing:ConfigureHealthCheck",
        "elasticloadbalancing:DeleteLoadBalancer",
        "elasticloadbalancing:DeleteLoadBalancerListeners",
        "elasticloadbalancing:DescribeLoadBalancers",
        "elasticloadbalancing:DescribeLoadBalancerAttributes",
        "elasticloadbalancing:DetachLoadBalancerFromSubnets",
        "elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
        "elasticloadbalancing:ModifyLoadBalancerAttributes",
        "elasticloadbalancing:RegisterInstancesWithLoadBalancer",
        "elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer",
        "elasticloadbalancing:CreateListener",
        "elasticloadbalancing:CreateTargetGroup",
        "elasticloadbalancing:DeleteListener",
        "elasticloadbalancing:DeleteTargetGroup",
        "elasticloadbalancing:DescribeListeners",
        "elasticloadbalancing:DescribeLoadBalancerPolicies",
        "elasticloadbalancing:DescribeTargetGroups",
        "elasticloadbalancing:DescribeTargetHealth",
        "elasticloadbalancing:ModifyListener",
        "elasticloadbalancing:ModifyTargetGroup",
        "elasticloadbalancing:RegisterTargets",
        "elasticloadbalancing:SetLoadBalancerPoliciesOfListener",
        "iam:CreateServiceLinkedRole",
        "kms:DescribeKey"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}

Required by all nodes

All nodes require these permissions in order to run, and are used by the AWS cloud provider run by kubelet.

If provisioning IAM roles using clusterawsadm, these will be set up as the nodes.cluster-api-provider-aws.sigs.k8s.io IAM Policy, and attached to the nodes.cluster-api-provider-aws.sigs.k8s.io IAM role.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstances",
        "ec2:DescribeRegions",
        "ecr:GetAuthorizationToken",
        "ecr:BatchCheckLayerAvailability",
        "ecr:GetDownloadUrlForLayer",
        "ecr:GetRepositoryPolicy",
        "ecr:DescribeRepositories",
        "ecr:ListImages",
        "ecr:BatchGetImage"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}

When using EKS, the AmazonEKSWorkerNodePolicy and AmazonEKS_CNI_Policy AWS managed policies will also be attached to nodes.cluster-api-provider-aws.sigs.k8s.io IAM role.

clusterawsadm

Kubernetes Cluster API Provider AWS Management Utility

Synopsis

clusterawsadm provides helpers for bootstrapping Kubernetes Cluster API Provider AWS. Use clusterawsadm to view required AWS Identity and Access Management (IAM) policies as JSON docs, or create IAM roles and instance profiles automatically using AWS CloudFormation.

clusterawsadm additionally helps provide credentials for use with clusterctl.

clusterawsadm [flags]

Examples

  # Create AWS Identity and Access Management (IAM) roles for use with
  # Kubernetes Cluster API Provider AWS.
  clusterawsadm bootstrap iam create-cloudformation-stack
  
  # Encode credentials for use with clusterctl init
  export AWS_B64ENCODED_CREDENTIALS=$(clusterawsadm bootstrap credentials encode-as-profile)
  clusterctl init --infrastructure aws

Options

  -h, --help    help for clusterawsadm
  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm ami - AMI commands
• clusterawsadm bootstrap - bootstrap commands
• clusterawsadm controller - controller commands
• clusterawsadm eks - Commands related to EKS
• clusterawsadm resource - Commands related to AWS resources
• clusterawsadm version - Print version of clusterawsadm

Auto generated by spf13/cobra on 14-Apr-2022

clusterawsadm resource

Commands related to AWS resources

Synopsis

All AWS resources related actions such as:

List of AWS resources created by CAPA

clusterawsadm resource [command] [flags]

Options

  -h, --help   help for resource

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm - Kubernetes Cluster API Provider AWS Management Utility
• clusterawsadm resource list - List all AWS resources created by CAPA

Auto generated by spf13/cobra on 14-Apr-2022

clusterawsadm resource list

List all AWS resources created by CAPA

Synopsis

List AWS resources directly created by CAPA based on region and cluster-name. There are some indirect resources like Cloudwatch alarms, rules, etc which are not directly created by CAPA, so those resources are not listed here. If region and cluster-name are not set, then it will throw an error.

clusterawsadm resource list [flags]

Examples

  # List AWS resources directly created by CAPA in given region and clustername
  clusterawsadm resource list --region=us-east-1 --cluster-name=test-cluster

Options

  -n, --cluster-name string   The name of the cluster where AWS resources created by CAPA
  -h, --help                  help for list
  -o, --output string         The output format of the results. Possible values: table, json, yaml (default "table")
  -r, --region string         The AWS region where resources are created by CAPA

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm resource - Commands related to AWS resources

Auto generated by spf13/cobra on 14-Apr-2022

clusterawsadm version

Print version of clusterawsadm

clusterawsadm version [flags]

Options

  -h, --help            help for version
  -o, --output string   Output format; available options are 'yaml', 'json' and 'short'

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm - Kubernetes Cluster API Provider AWS Management Utility

Auto generated by spf13/cobra on 14-Apr-2022

clusterawsadm ami

AMI commands

Synopsis

All AMI related actions such as:

Copy AMIs based on Kubernetes version, OS etc from an AWS account where AMIs are stored

     to the current AWS account (use case: air-gapped deployments)

(to be implemented) List available AMIs

clusterawsadm ami [command] [flags]

Options

  -h, --help   help for ami

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm - Kubernetes Cluster API Provider AWS Management Utility
• clusterawsadm ami copy - Copy AMIs from an AWS account to the AWS account which credentials are provided
• clusterawsadm ami encrypted-copy - Encrypt and copy AMI snapshot, then create an AMI with that snapshot
• clusterawsadm ami list - List AMIs from the default AWS account where AMIs are stored

Auto generated by spf13/cobra on 14-Apr-2022

clusterawsadm ami copy

Copy AMIs from an AWS account to the AWS account which credentials are provided

Synopsis

Copy AMIs based on Kubernetes version, OS, region from an AWS account where AMIs are stored to the current AWS account (use case: air-gapped deployments)

clusterawsadm ami copy [flags]

Examples

  # Copy AMI from the default AWS account where AMIs are stored.
  # Available os options: centos-7, ubuntu-18.04, ubuntu-20.04, amazon-2
  clusterawsadm ami copy --kubernetes-version=v1.18.12 --os=ubuntu-20.04  --region=us-west-2
  
  # owner-id and dry-run flags are optional. region can be set via flag or env
  clusterawsadm ami copy --os centos-7 --kubernetes-version=v1.19.4 --owner-id=111111111111 --dry-run
  
  # copy from us-east-1 to us-east-2
  clusterawsadm ami copy --os centos-7 --kubernetes-version=v1.19.4 --region us-east-2 --source-region us-east-1

Options

      --dry-run                     Check if AMI exists and can be copied
  -h, --help                        help for copy
      --kubernetes-version string   Kubernetes version of the AMI to be copied
      --os string                   Operating system of the AMI to be copied
      --owner-id string             The source AWS owner ID, where the AMI will be copied from (default "258751437250")
      --region string               The AWS region in which to provision
      --source-region string        Set if wanting to copy an AMI from a different region

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm ami - AMI commands

Auto generated by spf13/cobra on 14-Apr-2022

clusterawsadm ami encrypted-copy

Encrypt and copy AMI snapshot, then create an AMI with that snapshot

Synopsis

Find the AMI based on Kubernetes version, OS, region in the AWS account where AMIs are stored. Encrypt and copy the snapshot of the AMI to the current AWS account. Create an AMI with that snapshot.

clusterawsadm ami encrypted-copy [flags]

Examples

  # Create an encrypted AMI:
  # Available os options: centos-7, ubuntu-18.04, ubuntu-20.04, amazon-2
  clusterawsadm ami encrypted-copy --kubernetes-version=v1.18.12 --os=ubuntu-20.04  --region=us-west-2
  
  # owner-id and dry-run flags are optional. region can be set via flag or env
  clusterawsadm ami encrypted-copy --os centos-7 --kubernetes-version=v1.19.4 --owner-id=111111111111 --dry-run
  
  # copy from us-east-1 to us-east-2
  clusterawsadm ami encrypted-copy --os centos-7 --kubernetes-version=v1.19.4 --owner-id=111111111111 --region us-east-2 --source-region us-east-1
  
  # Encrypt using a non-default KmsKeyId specified using Key ID:
  clusterawsadm ami encrypted-copy --os centos-7 --kubernetes-version=v1.19.4 --kms-key-id=key/1234abcd-12ab-34cd-56ef-1234567890ab
  
  # Encrypt using a non-default KmsKeyId specified using Key alias:
  clusterawsadm ami encrypted-copy --os centos-7 --kubernetes-version=v1.19.4 --kms-key-id=alias/ExampleAlias
  
  # Encrypt using a non-default KmsKeyId specified using Key ARN:
  clusterawsadm ami encrypted-copy --os centos-7 --kubernetes-version=v1.19.4 --kms-key-id=arn:aws:kms:us-east-1:012345678910:key/abcd1234-a123-456a-a12b-a123b4cd56ef
  
  # Encrypt using a non-default KmsKeyId specified using Alias ARN:
  clusterawsadm ami encrypted-copy --os centos-7 --kubernetes-version=v1.19.4 --kms-key-id=arn:aws:kms:us-east-1:012345678910:alias/ExampleAlias

Options

      --dry-run                     Check if AMI exists and can be copied
  -h, --help                        help for encrypted-copy
      --kms-key-id string           The ID of the KMS key for Amazon EBS encryption
      --kubernetes-version string   Kubernetes version of the AMI to be copied
      --os string                   Operating system of the AMI to be copied
      --owner-id string             The source AWS owner ID, where the AMI will be copied from (default "258751437250")
      --region string               The AWS region in which to provision
      --source-region string        Set if wanting to copy an AMI from a different region

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm ami - AMI commands

Auto generated by spf13/cobra on 14-Apr-2022

clusterawsadm ami list

List AMIs from the default AWS account where AMIs are stored

Synopsis

List AMIs based on Kubernetes version, OS, region. If no arguments are provided, it will print all AMIs in all regions, OS types for the supported Kubernetes versions. Supported Kubernetes versions start from the latest stable version and goes 2 release back: if the latest stable release is v1.20.4- v1.19.x and v1.18.x are supported. Note: First release of each version will be skipped, e.g., v1.21.0 To list AMIs of unsupported Kubernetes versions, --kubernetes-version flag needs to be provided.

clusterawsadm ami list [flags]

Examples

  # List AMIs from the default AWS account where AMIs are stored.
  # Available os options: centos-7, ubuntu-18.04, ubuntu-20.04, amazon-2
  clusterawsadm ami list --kubernetes-version=v1.18.12 --os=ubuntu-20.04  --region=us-west-2
  # To list all supported AMIs in all supported Kubernetes versions, regions, and linux distributions:
  clusterawsadm ami list

Options

  -h, --help                        help for list
      --kubernetes-version string   Kubernetes version of the AMI to be copied
      --os string                   Operating system of the AMI to be copied
  -o, --output string               The output format of the results. Possible values: table,json,yaml (default "table")
      --region string               The AWS region in which to provision

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm ami - AMI commands

Auto generated by spf13/cobra on 14-Apr-2022

clusterawsadm bootstrap

bootstrap commands

Synopsis

In order to use Kubernetes Cluster API Provider AWS, an AWS account needs to be prepared with AWS Identity and Access Management (IAM) roles to be used by clusters as well as provide Kubernetes Cluster API Provider AWS with credentials to use to provision infrastructure.

clusterawsadm bootstrap [command] [flags]

Options

  -h, --help   help for bootstrap

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm - Kubernetes Cluster API Provider AWS Management Utility
• clusterawsadm bootstrap credentials - Encode credentials to use with Kubernetes Cluster API Provider AWS
• clusterawsadm bootstrap iam - View required AWS IAM policies and create/update IAM roles using AWS CloudFormation

Auto generated by spf13/cobra on 14-Apr-2022

clusterawsadm bootstrap credentials

Encode credentials to use with Kubernetes Cluster API Provider AWS

Synopsis

Encode credentials to use with Kubernetes Cluster API Provider AWS.

The utility will attempt to find credentials in the following order:

1. Check for the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables.
2. Read the default credentials from the shared configuration files ~/.aws/credentials or the default profile in ~/.aws/config.
3. Check for the presence of an EC2 IAM instance profile if it’s running on AWS.
4. Check for ECS credentials.

IAM role assumption can be performed by using any valid configuration for the AWS CLI at: https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html. For role assumption to be used, a region is required for the utility to use the AWS Security Token Service (STS). The utility resolves the region in the following order:

1. Check for the --region flag.
2. Check for the AWS_REGION environment variable.
3. Check for the DEFAULT_AWS_REGION environment variable.
4. Check that a region is specified in the shared configuration file.

The utility will then generate an ini-file with a default profile corresponding to the resolved credentials.

If a region cannot be found, for the purposes of using AWS Security Token Service, this utility will fall back to us-east-1. This does not affect the region in which clusters will be created.

In the case of an instance profile or role assumption, note that encoded credentials are time-limited.

clusterawsadm bootstrap credentials [flags]

Examples

  # Encode credentials from the environment for use with clusterctl
  export AWS_B64ENCODED_CREDENTIALS=$(clusterawsadm bootstrap credentials encode-as-profile)
  clusterctl init --infrastructure aws

Options

  -h, --help   help for credentials

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm bootstrap - bootstrap commands
• clusterawsadm bootstrap credentials encode-as-profile - Generate an AWS profile from the current environment

Auto generated by spf13/cobra on 14-Apr-2022

clusterawsadm bootstrap credentials encode-as-profile

Generate an AWS profile from the current environment

Synopsis

Generate an AWS profile from the current environment for the ephemeral bootstrap cluster.

The utility will attempt to find credentials in the following order:

1. Check for the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables.
2. Read the default credentials from the shared configuration files ~/.aws/credentials or the default profile in ~/.aws/config.
3. Check for the presence of an EC2 IAM instance profile if it’s running on AWS.
4. Check for ECS credentials.

IAM role assumption can be performed by using any valid configuration for the AWS CLI at: https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html. For role assumption to be used, a region is required for the utility to use the AWS Security Token Service (STS). The utility resolves the region in the following order:

1. Check for the --region flag.
2. Check for the AWS_REGION environment variable.
3. Check for the DEFAULT_AWS_REGION environment variable.
4. Check that a region is specified in the shared configuration file.

The utility will then generate an ini-file with a default profile corresponding to the resolved credentials.

If a region cannot be found, for the purposes of using AWS Security Token Service, this utility will fall back to us-east-1. This does not affect the region in which clusters will be created.

In the case of an instance profile or role assumption, note that encoded credentials are time-limited.

clusterawsadm bootstrap credentials encode-as-profile [flags]

Examples

  # Encode credentials from the environment for use with clusterctl
  export AWS_B64ENCODED_CREDENTIALS=$(clusterawsadm bootstrap credentials encode-as-profile)
  clusterctl init --infrastructure aws

Options

  -h, --help            help for encode-as-profile
      --output string   Output for credential configuration (rawSharedConfig, base64SharedConfig) (default "base64SharedConfig")
      --region string   The AWS region in which to provision

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm bootstrap credentials - Encode credentials to use with Kubernetes Cluster API Provider AWS

Auto generated by spf13/cobra on 14-Apr-2022

clusterawsadm bootstrap iam

View required AWS IAM policies and create/update IAM roles using AWS CloudFormation

Synopsis

View/output AWS Identity and Access Management (IAM) policy documents required for configuring Kubernetes Cluster API Provider AWS as well as create/update AWS IAM resources using AWS CloudFormation.

clusterawsadm bootstrap iam [command] [flags]

Options

  -h, --help   help for iam

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm bootstrap - bootstrap commands
• clusterawsadm bootstrap iam create-cloudformation-stack - Create or update an AWS CloudFormation stack
• clusterawsadm bootstrap iam delete-cloudformation-stack - Delete an AWS CloudFormation stack
• clusterawsadm bootstrap iam print-cloudformation-template - Print cloudformation template
• clusterawsadm bootstrap iam print-config - Print configuration
• clusterawsadm bootstrap iam print-policy - Generate and show an IAM policy

Auto generated by spf13/cobra on 14-Apr-2022

clusterawsadm bootstrap iam print-config

Print configuration

Synopsis

Print configuration

clusterawsadm bootstrap iam print-config [flags]

Examples

  # Print the default configuration.
  clusterawsadm bootstrap iam print-config
  
  # Apply defaults to a configuration file and print the result
  clusterawsadm bootstrap iam print-config --config bootstrap_config.yaml

Options

      --config string   clusterawsadm will load a bootstrap configuration from this file. The path may be
                        absolute or relative; relative paths start at the current working directory.
                        
                        The configuration file is a Kubernetes YAML using the
                        bootstrap.aws.infrastructure.cluster.x-k8s.io/v1beta1/AWSIAMConfiguration
                        kind.
                        
                        Documentation for this kind can be found at:
                        https://pkg.go.dev/sigs.k8s.io/cluster-api-provider-aws/cmd/clusterawsadm/api/bootstrap/v1beta1
                        
                        To see the default configuration, run 'clusterawsadm bootstrap iam print-config'.
  -h, --help            help for print-config

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm bootstrap iam - View required AWS IAM policies and create/update IAM roles using AWS CloudFormation

Auto generated by spf13/cobra on 14-Apr-2022

clusterawsadm bootstrap iam print-policy

Generate and show an IAM policy

Synopsis

Generate and show an AWS Identity and Access Management (IAM) policy for Kubernetes Cluster API Provider AWS.

clusterawsadm bootstrap iam print-policy [flags]

Examples

  # Print out the IAM policy for the Kubernetes Cluster API Provider AWS Controller.
  clusterawsadm bootstrap iam print-policy --document AWSIAMManagedPolicyControllers
  
  # Print out the IAM policy for the Kubernetes Cluster API Provider AWS Controller using a given configuration file.
  clusterawsadm bootstrap iam print-policy --document AWSIAMManagedPolicyControllers --config bootstrap_config.yaml
  
  # Print out the IAM policy for the Kubernetes AWS Cloud Provider for the control plane.
  clusterawsadm bootstrap iam print-policy --document AWSIAMManagedPolicyCloudProviderControlPlane
  
  # Print out the IAM policy for the Kubernetes AWS Cloud Provider for all nodes.
  clusterawsadm bootstrap iam print-policy --document AWSIAMManagedPolicyCloudProviderNodes
  
  # Print out the IAM policy for the Kubernetes AWS EBS CSI Driver Controller.
  clusterawsadm bootstrap iam print-policy --document AWSEBSCSIPolicyController

Options

      --config string     clusterawsadm will load a bootstrap configuration from this file. The path may be
                          absolute or relative; relative paths start at the current working directory.
                          
                          The configuration file is a Kubernetes YAML using the
                          bootstrap.aws.infrastructure.cluster.x-k8s.io/v1beta1/AWSIAMConfiguration
                          kind.
                          
                          Documentation for this kind can be found at:
                          https://pkg.go.dev/sigs.k8s.io/cluster-api-provider-aws/cmd/clusterawsadm/api/bootstrap/v1beta1
                          
                          To see the default configuration, run 'clusterawsadm bootstrap iam print-config'.
      --document string   which document to show: [AWSIAMManagedPolicyControllers AWSIAMManagedPolicyControllersEKS AWSIAMManagedPolicyCloudProviderControlPlane AWSIAMManagedPolicyCloudProviderNodes AWSEBSCSIPolicyController]
  -h, --help              help for print-policy

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm bootstrap iam - View required AWS IAM policies and create/update IAM roles using AWS CloudFormation

Auto generated by spf13/cobra on 14-Apr-2022

clusterawsadm bootstrap iam create-cloudformation-stack

Create or update an AWS CloudFormation stack

Synopsis

Create or update an AWS CloudFormation stack for bootstrapping Kubernetes Cluster API and Kubernetes AWS Identity and Access Management (IAM) permissions. To use this command, there must be AWS credentials loaded in this environment.

The utility will attempt to find credentials in the following order:

1. Check for the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables.
2. Read the default credentials from the shared configuration files ~/.aws/credentials or the default profile in ~/.aws/config.
3. Check for the presence of an EC2 IAM instance profile if it’s running on AWS.
4. Check for ECS credentials.

IAM role assumption can be performed by using any valid configuration for the AWS CLI at: https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html. For role assumption to be used, a region is required for the utility to use the AWS Security Token Service (STS). The utility resolves the region in the following order:

1. Check for the --region flag.
2. Check for the AWS_REGION environment variable.
3. Check for the DEFAULT_AWS_REGION environment variable.
4. Check that a region is specified in the shared configuration file.

clusterawsadm bootstrap iam create-cloudformation-stack [flags]

Examples

  # Create or update IAM roles and policies for Kubernetes using a AWS CloudFormation stack.
  clusterawsadm bootstrap iam create-cloudformation-stack
  
  # Create or update IAM roles and policies for Kubernetes using a AWS CloudFormation stack with a custom configuration.
  clusterawsadm bootstrap iam create-cloudformation-stack --config bootstrap_config.yaml

Options

      --config string   clusterawsadm will load a bootstrap configuration from this file. The path may be
                        absolute or relative; relative paths start at the current working directory.
                        
                        The configuration file is a Kubernetes YAML using the
                        bootstrap.aws.infrastructure.cluster.x-k8s.io/v1beta1/AWSIAMConfiguration
                        kind.
                        
                        Documentation for this kind can be found at:
                        https://pkg.go.dev/sigs.k8s.io/cluster-api-provider-aws/cmd/clusterawsadm/api/bootstrap/v1beta1
                        
                        To see the default configuration, run 'clusterawsadm bootstrap iam print-config'.
  -h, --help            help for create-cloudformation-stack
      --region string   The AWS region in which to provision

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm bootstrap iam - View required AWS IAM policies and create/update IAM roles using AWS CloudFormation

Auto generated by spf13/cobra on 14-Apr-2022

clusterawsadm bootstrap iam delete-cloudformation-stack

Delete an AWS CloudFormation stack

Synopsis

Delete the AWS CloudFormation stack that created AWS Identity and Access Management (IAM) resources for use with Kubernetes Cluster API Provider AWS.

clusterawsadm bootstrap iam delete-cloudformation-stack [flags]

Options

      --config string   clusterawsadm will load a bootstrap configuration from this file. The path may be
                        absolute or relative; relative paths start at the current working directory.
                        
                        The configuration file is a Kubernetes YAML using the
                        bootstrap.aws.infrastructure.cluster.x-k8s.io/v1beta1/AWSIAMConfiguration
                        kind.
                        
                        Documentation for this kind can be found at:
                        https://pkg.go.dev/sigs.k8s.io/cluster-api-provider-aws/cmd/clusterawsadm/api/bootstrap/v1beta1
                        
                        To see the default configuration, run 'clusterawsadm bootstrap iam print-config'.
  -h, --help            help for delete-cloudformation-stack
      --region string   The AWS region in which to provision

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm bootstrap iam - View required AWS IAM policies and create/update IAM roles using AWS CloudFormation

Auto generated by spf13/cobra on 14-Apr-2022

clusterawsadm bootstrap iam print-cloudformation-template

Print cloudformation template

Synopsis

Generate and print out a CloudFormation template that can be used to provision AWS Identity and Access Management (IAM) policies and roles for use with Kubernetes Cluster API Provider AWS.

clusterawsadm bootstrap iam print-cloudformation-template [flags]

Examples

  # Print out the default CloudFormation template.
  clusterawsadm bootstrap iam print-cloudformation-template
  
  # Print out a CloudFormation template using a custom configuration.
  clusterawsadm bootstrap iam print-cloudformation-template --config bootstrap_config.yaml

Options

      --config string   clusterawsadm will load a bootstrap configuration from this file. The path may be
                        absolute or relative; relative paths start at the current working directory.
                        
                        The configuration file is a Kubernetes YAML using the
                        bootstrap.aws.infrastructure.cluster.x-k8s.io/v1beta1/AWSIAMConfiguration
                        kind.
                        
                        Documentation for this kind can be found at:
                        https://pkg.go.dev/sigs.k8s.io/cluster-api-provider-aws/cmd/clusterawsadm/api/bootstrap/v1beta1
                        
                        To see the default configuration, run 'clusterawsadm bootstrap iam print-config'.
  -h, --help            help for print-cloudformation-template

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm bootstrap iam - View required AWS IAM policies and create/update IAM roles using AWS CloudFormation

Auto generated by spf13/cobra on 14-Apr-2022

clusterawsadm controller

controller commands

Synopsis

All controller related actions such as:

Zero controller credentials and rollout controllers

clusterawsadm controller [command] [flags]

Options

  -h, --help   help for controller

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm - Kubernetes Cluster API Provider AWS Management Utility
• clusterawsadm controller print-credentials - print credentials the controller is using
• clusterawsadm controller rollout-controller - initiates rollout and restart on capa-controller-manager deployment
• clusterawsadm controller update-credentials - update credentials the controller is using (i.e., update controller bootstrap secret)
• clusterawsadm controller zero-credentials - zero credentials the controller is started with

Auto generated by spf13/cobra on 14-Apr-2022

clusterawsadm controller print-credentials

print credentials the controller is using

Synopsis

print credentials the controller is using

clusterawsadm controller print-credentials [flags]

Examples

  # print credentials
  clusterawsadm controller print-credentials --kubeconfig=kubeconfig --namespace=capa-system

Options

  -h, --help                        help for print-credentials
      --kubeconfig string           Path to the kubeconfig file to use for the management cluster. If empty, default discovery rules apply.
      --kubeconfig-context string   Context to be used within the kubeconfig file. If empty, current context will be used.
      --namespace string            Namespace the controllers are in. If empty, default value (capa-system) is used (default "capa-system")

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm controller - controller commands

Auto generated by spf13/cobra on 14-Apr-2022

clusterawsadm controller rollout-controller

initiates rollout and restart on capa-controller-manager deployment

Synopsis

initiates rollout and restart on capa-controller-manager deployment

clusterawsadm controller rollout-controller [flags]

Examples

  # rollout controller deployment
  clusterawsadm controller rollout-controller --kubeconfig=kubeconfig --namespace=capa-system

Options

  -h, --help                        help for rollout-controller
      --kubeconfig string           Path to the kubeconfig file to use for the management cluster. If empty, default discovery rules apply.
      --kubeconfig-context string   Context to be used within the kubeconfig file. If empty, current context will be used.
      --namespace string            Namespace the controllers are in. If empty, default value (capa-system) is used (default "capa-system")

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm controller - controller commands

Auto generated by spf13/cobra on 14-Apr-2022

clusterawsadm controller update-credentials

update credentials the controller is using (i.e., update controller bootstrap secret)

Synopsis

Update credentials the controller is started with

clusterawsadm controller update-credentials [flags]

Examples

  # update credentials: AWS_B64ENCODED_CREDENTIALS environment variable must be set and be used to update the bootstrap secret
  # Kubeconfig file will be searched in default locations
  clusterawsadm controller update-credentials --namespace=capa-system
  # Provided kubeconfig file will be used
  clusterawsadm controller update-credentials --kubeconfig=kubeconfig  --namespace=capa-system
  # Kubeconfig in the default location will be retrieved and the provided context will be used
  clusterawsadm controller update-credentials --kubeconfig-context=mgmt-cluster  --namespace=capa-system

Options

  -h, --help                        help for update-credentials
      --kubeconfig string           Path to the kubeconfig file to use for the management cluster. If empty, default discovery rules apply.
      --kubeconfig-context string   Context to be used within the kubeconfig file. If empty, current context will be used.
      --namespace string            Namespace the controllers are in. If empty, default value (capa-system) is used (default "capa-system")

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm controller - controller commands

Auto generated by spf13/cobra on 14-Apr-2022

clusterawsadm controller zero-credentials

zero credentials the controller is started with

Synopsis

Zero credentials the controller is started with

clusterawsadm controller zero-credentials [flags]

Examples

  # zero credentials
  # Kubeconfig file will be searched in default locations
  clusterawsadm controller zero-credentials --namespace=capa-system
  # Provided kubeconfig file will be used
  clusterawsadm controller zero-credentials --kubeconfig=kubeconfig  --namespace=capa-system
  # Kubeconfig in the default location will be retrieved and the provided context will be used
  clusterawsadm controller zero-credentials --kubeconfig-context=mgmt-cluster  --namespace=capa-system

Options

  -h, --help                        help for zero-credentials
      --kubeconfig string           Path to the kubeconfig file to use for the management cluster. If empty, default discovery rules apply.
      --kubeconfig-context string   Context to be used within the kubeconfig file. If empty, current context will be used.
      --namespace string            Namespace the controllers are in. If empty, default value (capa-system) is used (default "capa-system")

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm controller - controller commands

Auto generated by spf13/cobra on 14-Apr-2022

clusterawsadm eks

Commands related to EKS

clusterawsadm eks [flags]

Options

  -h, --help   help for eks

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm - Kubernetes Cluster API Provider AWS Management Utility
• clusterawsadm eks addons - Commands related to EKS addons

Auto generated by spf13/cobra on 14-Apr-2022

clusterawsadm eks addons

Commands related to EKS addons

clusterawsadm eks addons [flags]

Options

  -h, --help   help for addons

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm eks - Commands related to EKS
• clusterawsadm eks addons list-available - List available EKS addons
• clusterawsadm eks addons list-installed - List installed EKS addons

Auto generated by spf13/cobra on 14-Apr-2022

clusterawsadm eks addons list-available

List available EKS addons

Synopsis

Lists the addons that are available for use with an EKS cluster

clusterawsadm eks addons list-available [flags]

Options

  -n, --cluster-name string   The name of the cluster to get the list of available addons for
  -h, --help                  help for list-available
  -o, --output string         The output format of the results. Possible values: table,json,yaml (default "table")
  -r, --region string         The AWS region containing the EKS cluster

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm eks addons - Commands related to EKS addons

Auto generated by spf13/cobra on 14-Apr-2022

clusterawsadm eks addons list-installed

List installed EKS addons

Synopsis

Lists the addons that are installed for an EKS cluster

clusterawsadm eks addons list-installed [flags]

Options

  -n, --cluster-name string   The name of the cluster to get the list of installed addons for
  -h, --help                  help for list-installed
  -o, --output string         The output format of the results. Possible values: table,json,yaml (default "table")
  -r, --region string         The AWS region containing the EKS cluster

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm eks addons - Commands related to EKS addons

Auto generated by spf13/cobra on 14-Apr-2022

Developer Guide

Initial setup for development environment

Install prerequisites

1. Install go
   • Get the latest patch version for go v1.16.
2. Install jq
   • brew install jq on macOS.
   • chocolatey install jq on Windows.
   • sudo apt install jq on Ubuntu Linux.
3. Install KIND
   • GO111MODULE="on" go get sigs.k8s.io/kind@v0.11.0.
4. Install Kustomize
   • brew install kustomize on macOS.
   • choco install kustomize on Windows.
   • install instructions on Linux
5. Install envsubst
6. Install make.
7. Install direnv
   • brew install direnv on macOS.

Get the source

Fork the cluster-api-provider-aws repo:

cd "$(go env GOPATH)"
mkdir sigs.k8s.io
cd sigs.k8s.io/
git clone git@github.com:<GITHUB USERNAME>/cluster-api-provider-aws.git
cd cluster-api-provider-aws
git remote add upstream git@github.com:kubernetes-sigs/cluster-api-provider-aws.git
git fetch upstream

Build clusterawsadm

Build clusterawsadm in cluster-api-provider-aws:

cd "$(go env GOPATH)"/src/sigs.k8s.io/cluster-api-provider-aws
make clusterawsadm
mv ./bin/clusterawsadm /usr/local/bin/clusterawsadm

Setup AWS Environment

Create bootstrap file and bootstrap IAM roles and policies using clusterawsadm

$ cat config-bootstrap.yaml

apiVersion: bootstrap.aws.infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSIAMConfiguration
spec:
  bootstrapUser:
    enable: true

$ clusterawsadm bootstrap iam create-cloudformation-stack
Attempting to create AWS CloudFormation stack cluster-api-provider-aws-sigs-k8s-io

Customizing the bootstrap permission

The IAM permissions can be customized by using a configuration file with clusterawsadm. For example, to create the default IAM role for use with managed machine pools:

$ cat config-bootstrap.yaml
apiVersion: bootstrap.aws.infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSIAMConfiguration
spec:
  bootstrapUser:
    enable: true
  eks:
    iamRoleCreation: false # Set to true if you plan to use the EKSEnableIAM feature flag to enable automatic creation of IAM roles
    managedMachinePool:
      disable: false # Set to false to enable creation of the default node role for managed machine pools

Use the configuration file to create the additional IAM role:

$ ./bin/clusterawsadm bootstrap iam create-cloudformation-stack --config=config-bootstrap.yaml
Attempting to create AWS CloudFormation stack cluster-api-provider-aws-sigs-k8s-io

If you don’t plan on using EKS then see the documentation on disabling EKS support.

Sample Output

When creating the CloudFormation stack using clusterawsadm you will see output similar to this:

Following resources are in the stack:

Resource                  |Type                                                                                |Status
AWS::IAM::Group           |cluster-api-provider-aws-s-AWSIAMGroupBootstrapper-ME9XZVCO2491                     |CREATE_COMPLETE
AWS::IAM::InstanceProfile |control-plane.cluster-api-provider-aws.sigs.k8s.io                                  |CREATE_COMPLETE
AWS::IAM::InstanceProfile |controllers.cluster-api-provider-aws.sigs.k8s.io                                    |CREATE_COMPLETE
AWS::IAM::InstanceProfile |nodes.cluster-api-provider-aws.sigs.k8s.io                                          |CREATE_COMPLETE
AWS::IAM::ManagedPolicy   |arn:aws:iam::xxx:policy/control-plane.cluster-api-provider-aws.sigs.k8s.io |CREATE_COMPLETE
AWS::IAM::ManagedPolicy   |arn:aws:iam::xxx:policy/nodes.cluster-api-provider-aws.sigs.k8s.io         |CREATE_COMPLETE
AWS::IAM::ManagedPolicy   |arn:aws:iam::xxx:policy/controllers.cluster-api-provider-aws.sigs.k8s.io   |CREATE_COMPLETE
AWS::IAM::Role            |control-plane.cluster-api-provider-aws.sigs.k8s.io                                  |CREATE_COMPLETE
AWS::IAM::Role            |controllers.cluster-api-provider-aws.sigs.k8s.io                                    |CREATE_COMPLETE
AWS::IAM::Role            |eks-controlplane.cluster-api-provider-aws.sigs.k8s.io                               |CREATE_COMPLETE
AWS::IAM::Role            |eks-nodegroup.cluster-api-provider-aws.sigs.k8s.io                                  |CREATE_COMPLETE
AWS::IAM::Role            |nodes.cluster-api-provider-aws.sigs.k8s.io                                          |CREATE_COMPLETE
AWS::IAM::User            |bootstrapper.cluster-api-provider-aws.sigs.k8s.io                                   |CREATE_COMPLETE

Set Environment Variables

• Create a security credentials in the bootstrapper.cluster-api-provider-aws.sigs.k8s.io IAM user that is created by cloud-formation stack and copy the AWS_ACCESS_KEY_ID and AWS_SECRETS_ACCESS_KEY. (Or use admin user credentials instead)

• Set AWS_B64ENCODED_CREDENTIALS environment variable

  export AWS_ACCESS_KEY_ID=AKIATEST
  export AWS_SECRET_ACCESS_KEY=TESTTEST
  export AWS_REGION=eu-west-1
  export AWS_B64ENCODED_CREDENTIALS=$(clusterawsadm bootstrap credentials encode-as-profile)
  

Running local management cluster for development

Before the next steps, make sure initial setup for development environment steps are complete.

There are two ways to build aws manager from local cluster-api-provider-aws source and run it in local kind cluster:

Option 1: Setting up Development Environment with Tilt

Tilt is a tool for quickly building, pushing, and reloading Docker containers as part of a Kubernetes deployment. Many of the Cluster API engineers use it for quick iteration. Please see our Tilt instructions to get started.

Option 2: The Old-fashioned way

Running cluster-api and cluster-api-provider-aws controllers in a kind cluster:

1. Create a local kind cluster
   • kind create cluster
2. Install core cluster-api controllers (the version must match the cluster-api version in go.mod)
   • clusterctl init --core cluster-api:v0.3.16 --bootstrap kubeadm:v0.3.16 --control-plane kubeadm:v0.3.16
3. Build cluster-api-provider-aws docker images
   • make e2e-image
4. Release manifests under ./out directory
   • RELEASE_TAG="e2e" make release-manifests
5. Apply the manifests
   • kubectl apply -f ./out/infrastructure.yaml

Developing Cluster API Provider AWS with Tilt

This document describes how to use kind and Tilt for a simplified workflow that offers easy deployments and rapid iterative builds. Before the next steps, make sure initial setup for development environment steps are complete.

Also, visit the Cluster API documentation on Tilt for more information on how to set up your development environment.

Create a kind cluster

First, make sure you have a kind cluster and that your KUBECONFIG is set up correctly:

kind create cluster

This local cluster will be running all the cluster api controllers and become the management cluster which then can be used to spin up workload clusters on AWS.

Get the source

Get the source for core cluster-api for development with Tilt along with cluster-api-provider-aws.

$ cd "$(go env GOPATH)"
$ mkdir sigs.k8s.io
$ cd sigs.k8s.io/
$ git clone git@github.com:kubernetes-sigs/cluster-api.git
$ cd cluster-api
$ git fetch upstream

Create a tilt-settings.json file

Next, create a tilt-settings.json file and place it in your local copy of cluster-api. Here is an example:

Example tilt-settings.json for CAPA managed clusters:

{
  "enable_providers": [
    "kubeadm-bootstrap",
    "kubeadm-control-plane",
    "aws"
  ],
  "allowed_contexts": [
    "kind-kind"
  ],
  "default_registry": "gcr.io/your-project-name-here",
  "provider_repos": [
    "/Users/username/go/src/sigs.k8s.io/cluster-api-provider-aws"
  ],
  "kustomize_substitutions": {
    "EXP_CLUSTER_RESOURCE_SET": "true",
    "EXP_MACHINE_POOL": "true",
    "EVENT_BRIDGE_INSTANCE_STATE": "true",
    "AWS_B64ENCODED_CREDENTIALS": "W2RlZmFZSZnRg=="
  }
}

Example tilt-settings.json for EKS managed clusters:

{
"default_registry": "gcr.io/your-project-name-here",
    "provider_repos": ["../cluster-api-provider-aws"],
    "enable_providers": ["eks-bootstrap", "eks-controlplane", "kubeadm-bootstrap", "kubeadm-control-plane", "aws"],
    "kustomize_substitutions": {
        "AWS_B64ENCODED_CREDENTIALS": "W2RlZmFZSZnRg==",
        "EXP_EKS": "true",
        "EXP_EKS_IAM": "true",
        "EXP_MACHINE_POOL": "true"
    },
    "extra_args": {
        "aws": ["--v=2"],
        "eks-bootstrap": ["--v=2"],
        "eks-controlplane": ["--v=2"]
    }
  }

Run Tilt!

To launch your development environment, run:

tilt up

kind cluster becomes a management cluster after this point, check the pods running on the kind cluster kubectl get pods -A.

Create workload clusters

Set the following variables for both CAPA and EKS managed clusters:

export AWS_SSH_KEY_NAME=<sshkeypair>
export KUBERNETES_VERSION=v1.20.2
export CLUSTER_NAME=capi-<test-clustename>
export CONTROL_PLANE_MACHINE_COUNT=1
export AWS_CONTROL_PLANE_MACHINE_TYPE=t3.large
export WORKER_MACHINE_COUNT=1
export AWS_NODE_MACHINE_TYPE=t3.large

Set the following variables for only EKS managed clusters:

export AWS_EKS_ROLE_ARN=arn:aws:iam::<accountid>:role/aws-service-role/eks.amazonaws.com/AWSServiceRoleForAmazonEKS
export EKS_KUBERNETES_VERSION=v1.15

Create CAPA managed workload cluster:

cat templates/cluster-template.yaml 
cat templates/cluster-template.yaml | $HOME/go/bin/envsubst > test-cluster.yaml
kubectl apply -f test-cluster.yaml

Create EKS workload cluster:

cat templates/cluster-template-eks.yaml 
cat templates/cluster-template-eks.yaml | $HOME/go/bin/envsubst > test-cluster.yaml
kubectl apply -f test-cluster.yaml

Check the tilt logs and wait for the clusters to be created.

Clean up

Before deleting the kind cluster, make sure you delete all the workload clusters.

kubectl delete cluster <clustername>
tilt up (ctrl-c)
kind delete cluster

Troubleshooting

• Make sure you have at least three available spaces EIP and NAT Gateways to be created
• If your git starts throwing this error

flag provided but not defined: -variables
Usage: envsubst [options...] <input>

you might need to reinstall the system envsubst

brew install gettetxt
# or
brew reinstall gettext

Make sure you specify which envsubst you are using

Coding Conventions

Below is a collection of conventions, guidlines and general tips for writing code for this project.

API Definitions

Don’t Expose 3rd Party Package Types

When adding new or modifying API types don’t expose 3rd party package types/enums via the CAPA API definitions. Instead create our own versions and where provide mapping functions.

For example:

- AWS SDK [InstaneState](https://docs.aws.amazon.com/sdk-for-go/api/service/ec2/)
- CAPA [InstanceState](https://github.com/kubernetes-sigs/cluster-api-provider-aws/blob/main/api/v1beta1/types.go#L560:L581)

Don’t use struct pointer slices

When adding new fields to an API type don’t use a slice of struct pointers. This can cause issues with the code generator for the conversion functions. Instead use struct slices.

For example:

Instead of this

	// Configuration options for the non root storage volumes.
	// +optional
	NonRootVolumes []*Volume `json:"nonRootVolumes,omitempty"`

use

	// Configuration options for the non root storage volumes.
	// +optional
	NonRootVolumes []Volume `json:"nonRootVolumes,omitempty"`

And then within the code you can check the length or range over the slice.

Cluster API Provider AWS Roadmap

This roadmap is a constant work in progress, subject to frequent revision. Dates are approximations.

Ongoing

• Documentation improvements

v0.5.x (v1alpha3+) - June/July 2020

• Consume Cluster API e2e testing framework
• Supporting multiple AWS accounts as Kubernetes objects
• Bootstrap failure detection
• Improved status conditions
• Spot instances support for Machines

v0.6 (v1alpha4) ~ Q4 2020

• Multiple topologies
• Machine load balancer implementation
• SNS/SQS-based updates from CloudWatch Events so we don’t have to poll AWS for updates

TBD

• Implement MachinePools - Autoscaling groups and instances
• Spot instance support for MachinePool ASG/Instance implementation
• MachinePool implementation backed by Spot Fleet
• Dual stack IPv4/IPv6 support
• Windows nodes
• Support for GPU instances and Elastic GPU
• FIPS/NIST/STIG compliance