diff --git a/doc_source/add-user-role.md b/doc_source/add-user-role.md index 030a1606..65a6204e 100644 --- a/doc_source/add-user-role.md +++ b/doc_source/add-user-role.md @@ -1,103 +1,142 @@ -# Managing users or IAM roles for your cluster +# Enabling IAM user and role access to your cluster Access to your cluster using AWS IAM entities is enabled by the [AWS IAM Authenticator for Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator), which runs on the Amazon EKS control plane\. The authenticator gets its configuration information from the `eks-auth` `ConfigMap`\. For all `aws-auth` `ConfigMap` settings, see [Full Configuration Format](https://github.com/kubernetes-sigs/aws-iam-authenticator#full-configuration-format) on GitHub\. ## Add IAM users or roles to your Amazon EKS cluster -When you create an Amazon EKS cluster, the AWS Identity and Access Management \(IAM\) entity user or role, such as a [federated user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) that creates the cluster, is automatically granted `system:masters` permissions in the cluster's role\-based access control \(RBAC\) configuration in the Amazon EKS control plane\. This IAM entity doesn't appear in any visible configuration, so make sure to keep track of which IAM entity originally created the cluster\. To grant additional AWS users or roles the ability to interact with your cluster, you must edit the `aws-auth` `ConfigMap` within Kubernetes\. +When you create an Amazon EKS cluster, the AWS Identity and Access Management \(IAM\) entity user or role, such as a [federated user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) that creates the cluster, is automatically granted `system:masters` permissions in the cluster's role\-based access control \(RBAC\) configuration in the Amazon EKS control plane\. This IAM entity doesn't appear in any visible configuration, so make sure to keep track of which IAM entity originally created the cluster\. To grant additional AWS users or roles the ability to interact with your cluster, you must edit the `aws-auth` `ConfigMap` within Kubernetes and create a Kubernetes `rolebinding` or `clusterrolebinding` with the name of a `group` that you specify in the `aws-auth` `ConfigMap`\. **Note** For more information about different IAM identities, see [Identities \(Users, Groups, and Roles\)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) in the *IAM User Guide*\. For more information on Kubernetes role\-based access control \(RBAC\) configuration, see [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)\. **To add an IAM user or role to an Amazon EKS cluster** -1. Ensure that the AWS credentials that `kubectl` is using are already authorized for your cluster\. The IAM user that created the cluster has these permissions by default\. +1. Determine which credentials `kubectl` is using to access your cluster\. On your computer, you can see which credentials `kubectl` uses with the following command\. Replace ***\~/\.kube/config*** with the path to your `kubeconfig` file if you don't use the default path\. -1. Open the `aws-auth` ConfigMap\. + ``` + cat ~/.kube/config + ``` + + Output + + ``` + ... + contexts: + - context: + cluster: my-cluster.region-code.eksctl.io + user: admin@my-cluster.region-code.eksctl.io + name: admin@my-cluster.region-code.eksctl.io + current-context: admin@my-cluster.region-code.eksctl.io + ... + ``` + + In the previous example output the credentials for a user named *admin* are configured for a cluster named *my\-cluster*\. If this is the user that created the cluster, then it already has access to your cluster\. If it's not the user that created the cluster, then you need to complete the remaining steps to enable cluster access for the user, if you haven't already\. + +1. Ensure that you have an existing Kubernetes `role` or `clusterrole` with the permissions \(`rules`\) that you want your IAM users to have access to in your cluster and that you have an existing Kubernetes `rolebinding` or `clusterrolebinding` that binds a Kubernetes `group` to the `role` or `clusterrole`\. For more information, see [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) in the Kubernetes documentation\. You can view all of your existing `roles`, `clusterroles`, `rolebindings`, and `clusterrolebindings` using the following commands\. + + ``` + kubectl get roles --all-namespaces + ``` + + ``` + kubectl get clusterroles --all-namespaces + ``` ``` - kubectl edit -n kube-system configmap/aws-auth + kubectl get rolebindings --all-namespaces ``` + + ``` + kubectl get clusterolebindings --all-namespaces + ``` + + You can then view the details of any of the resources using the following command\. You can replace *role* with **clusterrole**, **rolebinding**, or **clusterrolebinding**, replace *role\-name* with the resource name \(from the previous output\), and replace *kube\-system* with the namespace of the resource \(from the previous output\)\. + + ``` + kubectl describe role role-name -n kube-system + ``` + +1. \(Optional\) Create a `clusterrole` and `clusterrolebinding` or `role` and `rolebinding` to enable IAM users to view [nodes](view-nodes.md) and [workloads](view-workloads.md) in the AWS Management Console\. + + 1. You can enable users to view Kubernetes resources for: + + **The cluster** – This manifest creates a `clusterrole` and `clusterrolebinding`\. The group name in the file is `eks-console-dashboard-full-access-group`, which is the group that your IAM user or role needs to be mapped to in the `aws-auth` `ConfigMap`\. You can change the name of the `group` before applying it to your cluster, if desired, and then map your IAM user or role to that group in the `ConfigMap`\. + + ``` + curl -o eks-console-full-access.yaml https://amazon-eks.s3.us-west-2.amazonaws.com/docs/eks-console-full-access.yaml + ``` + + **A specific namespace** – This manifest creates a `role` and `rolebinding`\. The namespace in this file is `default`, so if you want to specify a different namespace, edit the file before applying it to your cluster\. The group name in the file is `eks-console-dashboard-restricted-access-group`, which is the group that your IAM user or role needs to be mapped to in the `aws-auth` `ConfigMap`\. You can change the name of the group before applying it to your cluster, if desired, and then map your IAM user or role to that group in the configmap\. + + ``` + curl -o eks-console-restricted-access.yaml https://amazon-eks.s3.us-west-2.amazonaws.com/docs/eks-console-restricted-access.yaml + ``` + + 1. Apply the appropriate manifest using one of the following commands\. + + ``` + kubectl apply -f eks-console-full-access.yaml + ``` + + ``` + kubectl apply -f eks-console-restricted-access.yaml + ``` + +1. Edit the `aws-auth` `ConfigMap`\. + + 1. Open the `ConfigMap` for editing\. + + ``` + kubectl edit -n kube-system configmap/aws-auth + ``` **Note** If you receive an error stating "`Error from server (NotFound): configmaps "aws-auth" not found`", then use the procedure in [Apply the `aws-auth` ConfigMap to your cluster](#aws-auth-configmap) to apply the stock `ConfigMap`\. - Example `ConfigMap`: - - ``` - apiVersion: v1 - data: - mapRoles: | - - groups: - - system:bootstrappers - - system:nodes - rolearn: arn:aws:iam::111122223333:role/eksctl-my-cluster-nodegroup-standard-wo-NodeInstanceRole-1WP3NUE3O6UCF - username: system:node:{{EC2PrivateDNSName}} - kind: ConfigMap - metadata: - creationTimestamp: "2021-12-13T14:22:56Z" - name: aws-auth - namespace: kube-system - resourceVersion: "1716" - uid: 8244df86-ca77-422d-9904-016e37ce4e10 - ``` - -1. Add your IAM users, roles, or AWS accounts to the `ConfigMap`\. You cannot add IAM groups to the `ConfigMap`\. - + **To add an IAM role \(for example, for [federated users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)\):** add the role details to the `mapRoles` section of the `ConfigMap`, under `data`\. Add this section if it does not already exist in the file\. Each entry supports the following parameters: - + **rolearn**: The ARN of the IAM role to add\. - + **username**: The user name within Kubernetes to map to the IAM role\. - + **groups**: A list of groups within Kubernetes to which the role is mapped\. For more information, see [Default Roles and Role Bindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings) in the Kubernetes documentation\. - + **To add an IAM user:** add the user details to the `mapUsers` section of the ConfigMap, under `data`\. Add this section if it does not already exist in the file\. Each entry supports the following parameters: - + **userarn**: The ARN of the IAM user to add\. - + **username**: The user name within Kubernetes to map to the IAM user\. - + **groups**: A list of groups within Kubernetes to which the user is mapped to\. For more information, see [Default Roles and Role Bindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings) in the Kubernetes documentation\. - - For example, the block below contains: - + A `mapRoles` section that adds the node instance role so that nodes can register themselves with the cluster\. - + A `mapUsers` section with the AWS users `admin` from the default AWS account, and `ops-user` from another AWS account\. Both users are added to the `system:masters` group\. - - Replace all *`example-values`* with your own values\. - - ``` - # Please edit the object below. Lines beginning with a '#' will be ignored, - # and an empty file will abort the edit. If an error occurs while saving this file will be - # reopened with the relevant failures. - # - apiVersion: v1 - data: - mapRoles: | - - rolearn: arn:aws:iam::111122223333:role/eksctl-my-cluster-nodegroup-standard-wo-NodeInstanceRole-1WP3NUE3O6UCF - username: system:node:{{EC2PrivateDNSName}} - groups: - - system:bootstrappers - - system:nodes - mapUsers: | - - userarn: arn:aws:iam::111122223333:user/admin - username: admin - groups: - - system:masters - - userarn: arn:aws:iam::444455556666:user/ops-user - username: ops-user - groups: - - system:masters - ``` - -1. Save the file and exit your text editor\. - -1. Ensure that the Kubernetes user or group that you mapped the IAM user or role to is bound to a Kubernetes role with a `RoleBinding` or `ClusterRoleBinding`\. For more information, see [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) in the Kubernetes documentation\. You can download the following example manifests that create a `clusterrole` and `clusterrolebinding` or a `role` and `rolebinding`: - + **View Kubernetes resources in all namespaces** – The group name in the file is `eks-console-dashboard-full-access-group`, which is the group that your IAM user or role needs to be mapped to in the `aws-auth` configmap\. You can change the name of the group before applying it to your cluster, if desired, and then map your IAM user or role to that group in the configmap\. Download the file from: - - ``` - https://amazon-eks.s3.us-west-2.amazonaws.com/docs/eks-console-full-access.yaml - ``` - + **View Kubernetes resources in a specific namespace** – The namespace in this file is `default`, so if you want to specify a different namespace, edit the file before applying it to your cluster\. The group name in the file is `eks-console-dashboard-restricted-access-group`, which is the group that your IAM user or role needs to be mapped to in the `aws-auth` configmap\. You can change the name of the group before applying it to your cluster, if desired, and then map your IAM user or role to that group in the configmap\. Download the file from: - - ``` - https://amazon-eks.s3.us-west-2.amazonaws.com/docs/eks-console-restricted-access.yaml - ``` - -1. \(Optional\) If you want the users you've added to the configmap to be able to [View nodes](view-nodes.md) or [View workloads](view-workloads.md) in the AWS Management Console, then the user or role must have both of the the following types of permissions: - + Kubernetes permissions to view the resources in Kubernetes - + IAM permissions to view the resources in the AWS Management Console\. For more information, see [View nodes and workloads for all clusters in the AWS Management Console](security_iam_id-based-policy-examples.md#policy_example3)\. + 1. Add your IAM users, roles, or AWS accounts to the `ConfigMap`\. You cannot add IAM groups to the `ConfigMap`\. + + **To add an IAM role \(for example, for [federated users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)\):** Add the role details to the `mapRoles` section of the `ConfigMap`, under `data`\. Add this section if it does not already exist in the file\. Each entry supports the following parameters: + + **rolearn**: The ARN of the IAM role to add\. This value can't include a path\. The format of the value you provide must be `arn:aws:iam::111122223333:role/role-name`\. For more information, see [aws\-auth ConfigMap does not grant access to the cluster](troubleshooting_iam.md#security-iam-troubleshoot-ConfigMap)\. + + **username**: The user name within Kubernetes to map to the IAM role\. + + **groups**: A list of groups within Kubernetes to which the role is mapped\. For more information, see [Default Roles and Role Bindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings) in the Kubernetes documentation\. + + **To add an IAM user:** Add the user details to the `mapUsers` section of the ConfigMap, under `data`\. Add this section if it does not already exist in the file\. Each entry supports the following parameters: + + **userarn**: The ARN of the IAM user to add\. + + **username**: The user name within Kubernetes to map to the IAM user\. + + **groups**: A list of groups within Kubernetes to which the user is mapped to\. For more information, see [Default Roles and Role Bindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings) in the Kubernetes documentation\. + + For example, the block below contains: + + A `mapRoles` section that adds the node instance role so that nodes can register themselves with the cluster\. + + A `mapUsers` section with the AWS users `admin` from the default AWS account, and two operations users from a different AWS account\. The `admin` user is added to the `system:masters` Kubernetes group\. + + The operations users are added to Kubernetes groups that are used by the `role` and `rolebinding` and `clusterrole` and `clusterrolebinding` created by the manifests in the previous step, but you can replace them with whatever group you like\. To enable users to view [nodes](view-nodes.md) and [workloads](view-workloads.md) in the AWS Management Console, they must have the mapping in the following example and the `role` and `rolebinding` or the `clusterrole` and `clusterrolebinding` created by the manifests in the previous step\. + + Replace all *`example-values`* with your own values\. + + ``` + # Please edit the object below. Lines beginning with a '#' will be ignored, + # and an empty file will abort the edit. If an error occurs while saving this file will be + # reopened with the relevant failures. + # + apiVersion: v1 + data: + mapRoles: | + - rolearn: arn:aws:iam::111122223333:role/eksctl-my-cluster-nodegroup-standard-wo-NodeInstanceRole-1WP3NUE3O6UCF + username: system:node:{{EC2PrivateDNSName}} + groups: + - system:bootstrappers + - system:nodes + mapUsers: | + - userarn: arn:aws:iam::111122223333:user/admin + username: admin + groups: + - system:masters + - userarn: arn:aws:iam::444455556666:user/ops-user + username: ops-user + groups: + - eks-console-dashboard-full-access-group + - userarn: arn:aws:iam::444455556666:user/ops-user2 + username: ops-user2 + groups: + - eks-console-dashboard-restricted-access-group + ``` + + 1. Save the file and exit your text editor\. ## Apply the `aws-auth` ConfigMap to your cluster diff --git a/doc_source/alb-ingress.md b/doc_source/alb-ingress.md index 56e65017..3807ce79 100644 --- a/doc_source/alb-ingress.md +++ b/doc_source/alb-ingress.md @@ -18,10 +18,10 @@ Before you can load balance application traffic to an application, you must meet + **Key** – `kubernetes.io/cluster/cluster-name` + **Value** – `shared` or `owned` + Your public and private subnets must meet the following requirements\. This is unless you explicitly specify subnet IDs as an annotation on a Service or Ingress object\. Assume that you provision load balancers by explicitly specifying subnet IDs as an annotation on a Service or Ingress object\. In this situation, Kubernetes and the AWS load balancer controller use those subnets directly to create the load balancer and the following tags aren't required\. - + **Private subnets** – Must be tagged in the following format\. This is so that Kubernetes and the AWS load balancer controller know that the subnets can be used for internal load balancers\. If you use `eksctl` or an Amazon EKS AWS CloudFormation template to create your VPC after March 26, 2020, the subnets are tagged appropriately when created\. For more information about the Amazon EKS AWS CloudFormation VPC templates, see [Creating a VPC for your Amazon EKS cluster](create-public-private-vpc.md)\. + + **Private subnets** – Must be tagged in the following format\. This is so that Kubernetes and the AWS load balancer controller know that the subnets can be used for internal load balancers\. If you use `eksctl` or an Amazon EKS AWS CloudFormation template to create your VPC after March 26, 2020, the subnets are tagged appropriately when created\. For more information about the Amazon EKS AWS CloudFormation VPC templates, see [Creating a VPC for your Amazon EKS cluster](creating-a-vpc.md)\. + **Key** – `kubernetes.io/role/internal-elb` + **Value** – `1` - + **Public subnets** – Must be tagged in the following format\. This is so that Kubernetes knows to use only the subnets that were specified for external load balancers\. This way, Kubernetes doesn't choose a public subnet in each Availability Zone \(lexicographically based on their subnet ID\)\. If you use `eksctl` or an Amazon EKS AWS CloudFormation template to create your VPC after March 26, 2020, the subnets are tagged appropriately when created\. For more information about the Amazon EKS AWS CloudFormation VPC templates, see [Creating a VPC for your Amazon EKS cluster](create-public-private-vpc.md)\. + + **Public subnets** – Must be tagged in the following format\. This is so that Kubernetes knows to use only the subnets that were specified for external load balancers\. This way, Kubernetes doesn't choose a public subnet in each Availability Zone \(lexicographically based on their subnet ID\)\. If you use `eksctl` or an Amazon EKS AWS CloudFormation template to create your VPC after March 26, 2020, the subnets are tagged appropriately when created\. For more information about the Amazon EKS AWS CloudFormation VPC templates, see [Creating a VPC for your Amazon EKS cluster](creating-a-vpc.md)\. + **Key** – `kubernetes.io/role/elb` + **Value** – `1` diff --git a/doc_source/authenticate-oidc-identity-provider.md b/doc_source/authenticate-oidc-identity-provider.md index 87c15d55..427bfbf5 100644 --- a/doc_source/authenticate-oidc-identity-provider.md +++ b/doc_source/authenticate-oidc-identity-provider.md @@ -1,6 +1,6 @@ # Authenticating users for your cluster from an OpenID Connect identity provider -Amazon EKS supports using OpenID Connect \(OIDC\) identity providers as a method to authenticate users to your cluster\. OIDC identity providers can be used with, or as an alternative to AWS Identity and Access Management \(IAM\)\. For more information about using IAM, see [Managing users or IAM roles for your cluster](add-user-role.md)\. After configuring authentication to your cluster, you can create Kubernetes `roles` and `clusterroles` to assign permissions to the roles, and then bind the roles to the identities using Kubernetes `rolebindings` and `clusterrolebindings`\. For more information, see [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) in the Kubernetes documentation\. +Amazon EKS supports using OpenID Connect \(OIDC\) identity providers as a method to authenticate users to your cluster\. OIDC identity providers can be used with, or as an alternative to AWS Identity and Access Management \(IAM\)\. For more information about using IAM, see [Enabling IAM user and role access to your cluster](add-user-role.md)\. After configuring authentication to your cluster, you can create Kubernetes `roles` and `clusterroles` to assign permissions to the roles, and then bind the roles to the identities using Kubernetes `rolebindings` and `clusterrolebindings`\. For more information, see [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) in the Kubernetes documentation\. **Considerations** + Your cluster must be running Kubernetes 1\.16 or later\. diff --git a/doc_source/cluster-endpoint.md b/doc_source/cluster-endpoint.md index 9a9a3f38..fda01ce1 100644 --- a/doc_source/cluster-endpoint.md +++ b/doc_source/cluster-endpoint.md @@ -138,7 +138,7 @@ If you have disabled public access for your cluster's Kubernetes API server endp + **Connected network** – Connect your network to the VPC with an [AWS transit gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) or other [connectivity](https://docs.aws.amazon.com/aws-technical-content/latest/aws-vpc-connectivity-options/introduction.html) option and then use a computer in the connected network\. You must ensure that your Amazon EKS control plane security group contains rules to allow ingress traffic on port 443 from your connected network\. + **Amazon EC2 bastion host** – You can launch an Amazon EC2 instance into a public subnet in your cluster's VPC and then log in via SSH into that instance to run `kubectl` commands\. For more information, see [Linux bastion hosts on AWS](http://aws.amazon.com/quickstart/architecture/linux-bastion/)\. You must ensure that your Amazon EKS control plane security group contains rules to allow ingress traffic on port 443 from your bastion host\. For more information, see [Amazon EKS security group considerations](sec-group-reqs.md)\. - When you configure `kubectl` for your bastion host, be sure to use AWS credentials that are already mapped to your cluster's RBAC configuration, or add the IAM user or role that your bastion will use to the RBAC configuration before you remove endpoint public access\. For more information, see [Managing users or IAM roles for your cluster](add-user-role.md) and [Unauthorized or access denied \(`kubectl`\)](troubleshooting.md#unauthorized)\. + When you configure `kubectl` for your bastion host, be sure to use AWS credentials that are already mapped to your cluster's RBAC configuration, or add the IAM user or role that your bastion will use to the RBAC configuration before you remove endpoint public access\. For more information, see [Enabling IAM user and role access to your cluster](add-user-role.md) and [Unauthorized or access denied \(`kubectl`\)](troubleshooting.md#unauthorized)\. + **AWS Cloud9 IDE** – AWS Cloud9 is a cloud\-based integrated development environment \(IDE\) that lets you write, run, and debug your code with just a browser\. You can create an AWS Cloud9 IDE in your cluster's VPC and use the IDE to communicate with your cluster\. For more information, see [Creating an environment in AWS Cloud9](https://docs.aws.amazon.com/cloud9/latest/user-guide/create-environment.html)\. You must ensure that your Amazon EKS control plane security group contains rules to allow ingress traffic on port 443 from your IDE security group\. For more information, see [Amazon EKS security group considerations](sec-group-reqs.md)\. - When you configure `kubectl` for your AWS Cloud9 IDE, be sure to use AWS credentials that are already mapped to your cluster's RBAC configuration, or add the IAM user or role that your IDE will use to the RBAC configuration before you remove endpoint public access\. For more information, see [Managing users or IAM roles for your cluster](add-user-role.md) and [Unauthorized or access denied \(`kubectl`\)](troubleshooting.md#unauthorized)\. \ No newline at end of file + When you configure `kubectl` for your AWS Cloud9 IDE, be sure to use AWS credentials that are already mapped to your cluster's RBAC configuration, or add the IAM user or role that your IDE will use to the RBAC configuration before you remove endpoint public access\. For more information, see [Enabling IAM user and role access to your cluster](add-user-role.md) and [Unauthorized or access denied \(`kubectl`\)](troubleshooting.md#unauthorized)\. \ No newline at end of file diff --git a/doc_source/create-cluster.md b/doc_source/create-cluster.md index ef1fb0a2..a38cf1f5 100644 --- a/doc_source/create-cluster.md +++ b/doc_source/create-cluster.md @@ -5,7 +5,7 @@ This topic walks you through creating an Amazon EKS cluster\. If this is your fi To connect an external Kubernetes cluster to view in Amazon EKS, see [Amazon EKS Connector](eks-connector.md)\. **Important** -When an Amazon EKS cluster is created, the IAM entity \(user or role\) that creates the cluster is added to the Kubernetes RBAC authorization table as the administrator \(with `system:masters` permissions\)\. Initially, only that IAM user can make calls to the Kubernetes API server using `kubectl`\. For more information, see [Managing users or IAM roles for your cluster](add-user-role.md)\. If you use the console to create the cluster, you must ensure that the same IAM user credentials are in the AWS SDK credential chain when you are running `kubectl` commands on your cluster\. +When an Amazon EKS cluster is created, the IAM entity \(user or role\) that creates the cluster is added to the Kubernetes RBAC authorization table as the administrator \(with `system:masters` permissions\)\. Initially, only that IAM user can make calls to the Kubernetes API server using `kubectl`\. For more information, see [Enabling IAM user and role access to your cluster](add-user-role.md)\. If you use the console to create the cluster, you must ensure that the same IAM user credentials are in the AWS SDK credential chain when you are running `kubectl` commands on your cluster\. You can create a cluster with `eksctl`, the AWS Management Console, or the AWS CLI\. @@ -13,7 +13,7 @@ You can create a cluster with `eksctl`, the AWS Management Console, or the AWS C #### [ eksctl ] **Prerequisite** -`eksctl` version 0\.76\.0 or later installed\. To install it or upgrade, see [The `eksctl` command line utility](eksctl.md)\. +`eksctl` version 0\.77\.0 or later installed\. To install it or upgrade, see [The `eksctl` command line utility](eksctl.md)\. Create an Amazon EKS cluster with the Amazon EKS latest Kubernetes version in your default Region\. Replace the `` \(including `<>`\) with your own values\. You can replace `<1.20>` with any [supported version](kubernetes-versions.md)\. @@ -47,7 +47,7 @@ After your 1\.18 or later cluster is created, you can migrate the Amazon VPC CNI #### [ AWS Management Console ] **Prerequisites** -+ An existing VPC and a dedicated security group that meet the requirements for an Amazon EKS cluster\. For more information, see [Cluster VPC considerations](network_reqs.md) and [Amazon EKS security group considerations](sec-group-reqs.md)\. If you don't have a VPC, you can follow [Creating a VPC for your Amazon EKS cluster](create-public-private-vpc.md) to create one\. ++ An existing VPC and a dedicated security group that meet the requirements for an Amazon EKS cluster\. For more information, see [Cluster VPC considerations](network_reqs.md) and [Amazon EKS security group considerations](sec-group-reqs.md)\. If you don't have a VPC, you can follow [](creating-a-vpc.md) to create one\. + An existing Amazon EKS cluster IAM role\. If you don't have the role, you can follow [Amazon EKS IAM roles](security_iam_service-with-iam.md#security_iam_service-with-iam-roles) to create one\. **To create your cluster with the console** @@ -73,13 +73,13 @@ Deletion of the KMS key will permanently put the cluster in a degraded state\. I 1. Select **Next**\. 1. On the **Specify networking** page, select values for the following fields: - + **VPC** – Select an existing VPC to use for your cluster\. If none are listed, then you need to create one first\. For more information, see [Creating a VPC for your Amazon EKS cluster](create-public-private-vpc.md)\. + + **VPC** – Select an existing VPC to use for your cluster\. If none are listed, then you need to create one first\. For more information, see [Creating a VPC for your Amazon EKS cluster](creating-a-vpc.md)\. + **Subnets** – By default, the available subnets in the VPC specified in the previous field are preselected\. Unselect any subnet that you don't want to host cluster resources, such as worker nodes or load balancers\. The subnets must meet the requirements for an Amazon EKS cluster\. For more information, see [Cluster VPC considerations](network_reqs.md)\. **Important** -If you select subnets that were created before March 26, 2020 using one of the Amazon EKS AWS CloudFormation VPC templates, be aware of a default setting change that was introduced on March 26, 2020\. For more information, see [Creating a VPC for your Amazon EKS cluster](create-public-private-vpc.md)\. +If you select subnets that were created before March 26, 2020 using one of the Amazon EKS AWS CloudFormation VPC templates, be aware of a default setting change that was introduced on March 26, 2020\. For more information, see [Creating a VPC for your Amazon EKS cluster](creating-a-vpc.md)\. Don't select subnets in AWS Outposts, AWS Wavelength or AWS Local Zones\. If you plan to deploy self\-managed nodes in AWS Outposts, AWS Wavelength or AWS Local Zones subnets after you deploy your cluster, then make sure that you have, or can create, Outposts subnets in the VPC that you select\. - **Security groups** – The **SecurityGroups** value from the AWS CloudFormation output that you generated when you created your [VPC](create-public-private-vpc.md)\. This security group has **ControlPlaneSecurityGroup** in the drop\-down name\. + **Security groups** – The **SecurityGroups** value from the AWS CloudFormation output that you generated when you created your [VPC](creating-a-vpc.md)\. This security group has **ControlPlaneSecurityGroup** in the drop\-down name\. **Important** The node AWS CloudFormation template modifies the security group that you specify here, so **Amazon EKS strongly recommends that you use a dedicated security group for each cluster control plane \(one per cluster\)**\. If this security group is shared with other resources, you might block or disrupt connections to those resources\. + \(Optional\) Choose **Configure Kubernetes Service IP address range** and specify a **Service IPv4 range** if you want to specify which CIDR block Kubernetes assigns service IP addresses from\. The CIDR block must meet the following requirements: @@ -127,13 +127,13 @@ You might receive an error that one of the Availability Zones in your request do #### [ AWS CLI ] **Prerequisites** -+ An existing VPC and a dedicated security group that meet the requirements for an Amazon EKS cluster\. For more information, see [Cluster VPC considerations](network_reqs.md) and [Amazon EKS security group considerations](sec-group-reqs.md)\. If you don't have a VPC, you can follow [Creating a VPC for your Amazon EKS cluster](create-public-private-vpc.md) to create one\. ++ An existing VPC and a dedicated security group that meet the requirements for an Amazon EKS cluster\. For more information, see [Cluster VPC considerations](network_reqs.md) and [Amazon EKS security group considerations](sec-group-reqs.md)\. If you don't have a VPC, you can follow [Creating a VPC for your Amazon EKS cluster](creating-a-vpc.md) to create one\. + An existing Amazon EKS cluster IAM role\. If you don't have the role, you can follow [Amazon EKS IAM roles](security_iam_service-with-iam.md#security_iam_service-with-iam-roles) to create one\. + The AWS CLI version 2\.3\.7 or later or 1\.22\.8 or later installed\. To install or upgrade, see [Installing, updating, and uninstalling the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) in the AWS Command Line Interface User Guide\. We recommend that you also configure the AWS CLI\. For more information, see [Quick configuration with `aws configure`](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) in the AWS Command Line Interface User Guide\. **To create your cluster with the AWS CLI** -1. Create your cluster with the following command\. Replace the Amazon Resource Name \(ARN\) of your Amazon EKS cluster IAM role that you created in [Amazon EKS cluster IAM role](service_IAM_role.md) and the subnet and security group IDs for the VPC that you created in [Creating a VPC for your Amazon EKS cluster](create-public-private-vpc.md)\. Replace `` \(including *<>*\) with your cluster name and `` with a [supported Region](https://docs.aws.amazon.com/general/latest/gr/eks.html#eks_region)\. You can replace `<1.21>` with any [supported version](kubernetes-versions.md)\. +1. Create your cluster with the following command\. Replace the Amazon Resource Name \(ARN\) of your Amazon EKS cluster IAM role that you created in [Amazon EKS cluster IAM role](service_IAM_role.md) and the subnet and security group IDs for the VPC that you created in [Creating a VPC for your Amazon EKS cluster](creating-a-vpc.md)\. Replace `` \(including *<>*\) with your cluster name and `` with a [supported Region](https://docs.aws.amazon.com/general/latest/gr/eks.html#eks_region)\. You can replace `<1.21>` with any [supported version](kubernetes-versions.md)\. For `subnetIds`, don't specify subnets in AWS Outposts, AWS Wavelength or AWS Local Zones\. If you plan to deploy self\-managed nodes in AWS Outposts, AWS Wavelength or AWS Local Zones subnets after you deploy your cluster, then make sure that you have, or can create, Outposts subnets in the VPC that you specify\. diff --git a/doc_source/create-managed-node-group.md b/doc_source/create-managed-node-group.md index 6add5f85..47834fa6 100644 --- a/doc_source/create-managed-node-group.md +++ b/doc_source/create-managed-node-group.md @@ -20,7 +20,7 @@ You can create a managed node group with `eksctl` or the AWS Management Console\ **To create a managed node group with `eksctl`** -This procedure requires `eksctl` version `0.76.0` or later\. You can check your version with the following command: +This procedure requires `eksctl` version `0.77.0` or later\. You can check your version with the following command: ``` eksctl version @@ -147,7 +147,7 @@ Amazon EKS doesn't automatically scale your node group in or out\. However, you **Important** If you are running a stateful application across multiple Availability Zones that is backed by Amazon EBS volumes and using the Kubernetes [Cluster Autoscaler](autoscaling.md#cluster-autoscaler), you should configure multiple node groups, each scoped to a single Availability Zone\. In addition, you should enable the `--balance-similar-node-groups` feature\. **Important** -If you choose a public subnet, and your cluster has only the public API server endpoint enabled, then the subnet must have `MapPublicIPOnLaunch` set to `true` for the instances to successfully join a cluster\. If the subnet was created using `eksctl` or the [Amazon EKS vended AWS CloudFormation templates](create-public-private-vpc.md) on or after March 26, 2020, then this setting is already set to `true`\. If the subnets were created with `eksctl` or the AWS CloudFormation templates before March 26, 2020, then you need to change the setting manually\. For more information, see [Modifying the public IPv4 addressing attribute for your subnet](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip)\. +If you choose a public subnet, and your cluster has only the public API server endpoint enabled, then the subnet must have `MapPublicIPOnLaunch` set to `true` for the instances to successfully join a cluster\. If the subnet was created using `eksctl` or the [Amazon EKS vended AWS CloudFormation templates](creating-a-vpc.md) on or after March 26, 2020, then this setting is already set to `true`\. If the subnets were created with `eksctl` or the AWS CloudFormation templates before March 26, 2020, then you need to change the setting manually\. For more information, see [Modifying the public IPv4 addressing attribute for your subnet](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip)\. If you use a launch template and specify multiple network interfaces, Amazon EC2 won't auto\-assign a public IPv4 address, even if `MapPublicIpOnLaunch` is set to `true`\. For nodes to join the cluster in this scenario, you must either enable the cluster's private API server endpoint, or launch nodes in a private subnet with outbound internet access provided through an alternative method, such as a NAT Gateway\. For more information, see [Amazon EC2 instance IP addressing](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html) in the *Amazon EC2 User Guide for Linux Instances*\. + **Configure SSH access to nodes** \(Optional\)\. Enabling SSH allows you to connect to your instances and gather diagnostic information if there are issues\. Complete the following steps to enable remote access\. We highly recommend enabling remote access when you create your node group\. You can't enable remote access after the node group is created\. @@ -176,7 +176,7 @@ If you use a launch template and specify multiple network interfaces, Amazon EC2 ------ Now that you have a working Amazon EKS cluster with nodes, you're ready to start installing Kubernetes add\-ons and deploying applications to your cluster\. The following documentation topics help you to extend the functionality of your cluster\. -+ The IAM entity \(user or role\) that created the cluster is the only IAM user can make calls to the Kubernetes API server using `kubectl`\. If you want other users to have access to your cluster, see [Managing users or IAM roles for your cluster](add-user-role.md)\. ++ The IAM entity \(user or role\) that created the cluster is the only IAM user can make calls to the Kubernetes API server using `kubectl`\. If you want other users to have access to your cluster, see [Enabling IAM user and role access to your cluster](add-user-role.md)\. + Restrict access to the instance metadata service – If you plan to assign IAM roles to all of your Kubernetes service accounts so that pods only have the minimum permissions that they need, and no pods in the cluster require access to the Amazon EC2 instance metadata service \(IMDS\) for other reasons, such as retrieving the current Region, then we recommend blocking pod access to IMDS\. For more information, see [Restrict access to the instance profile assigned to the worker node](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)\. + [Cluster Autoscaler](autoscaling.md#cluster-autoscaler) – Configure the Kubernetes Cluster Autoscaler to automatically adjust the number of nodes in your node groups\. + Deploy a [sample application](sample-deployment.md) to your cluster\. diff --git a/doc_source/create-service-account-iam-policy-and-role.md b/doc_source/create-service-account-iam-policy-and-role.md index 36ed8d5d..ef83ccb1 100644 --- a/doc_source/create-service-account-iam-policy-and-role.md +++ b/doc_source/create-service-account-iam-policy-and-role.md @@ -18,7 +18,7 @@ In this procedure, we offer two example policies that you can use for your appli 1. In the **Policy Document** field, paste one of the following policies to apply to your service accounts, or paste your own policy document into the field\. You can also use the visual editor to construct your own policy\. - The example below allows permission to the ** Amazon S3 bucket\. You can modify the policy document to suit your specific needs\. + The example below allows permission to the *my\-pod\-secrets\-bucket* Amazon S3 bucket\. You can modify the policy document to suit your specific needs\. ``` { @@ -30,7 +30,7 @@ In this procedure, we offer two example policies that you can use for your appli "s3:GetObject" ], "Resource": [ - "arn:aws:s3:::/*" + "arn:aws:s3:::my-pod-secrets-bucket/*" ] } ] @@ -74,19 +74,19 @@ You can create the IAM role with `eksctl`, the AWS Management Console, or the AW ------ #### [ eksctl ] -Create the service account and IAM role with the following command\. Replace the *``* \(including *`<>`*\) with your own values\. +Create the service account and IAM role with the following command\. Replace the *`example values`* with your own values\. ``` eksctl create iamserviceaccount \ - --name \ - --namespace \ - --cluster \ - --attach-policy-arn \ + --name kubernetes_service_account_name \ + --namespace kubernetes_service_account_namespace \ + --cluster cluster_name \ + --attach-policy-arn IAM_policy_ARN \ --approve \ --override-existing-serviceaccounts ``` -An AWS CloudFormation template is deployed that creates an IAM role and attaches the IAM policy to it\. The role is associated with a Kubernetes service account\. If your cluster didn't have an existing IAM OIDC provider, one was created\. If the service account doesn't exist, it is created in the namespace that you provided\. If the service account does exist, then it is annotated with `eks.amazonaws.com/role-arn:arn:aws:iam:::role/`\. +An AWS CloudFormation template is deployed that creates an IAM role and attaches the IAM policy to it\. The role is associated with a Kubernetes service account\. If your cluster didn't have an existing IAM OIDC provider, one was created\. If the service account doesn't exist, it is created in the namespace that you provided\. If the service account does exist, then it is annotated with `eks.amazonaws.com/role-arn:arn:aws:iam::your-account-id:role/iam-role-name-that-was-created`\. ------ #### [ AWS Management Console ] @@ -129,10 +129,10 @@ An AWS CloudFormation template is deployed that creates an IAM role and attaches "oidc.eks.region-code/id/EXAMPLED539D4633E53DE1B716D3041E:aud": "sts.amazonaws.com" ``` - Change the line to look like the following line\. Replace *``* \(including *`<>`*\)with your cluster's OIDC provider ID and replace ** with the Region code that your cluster is in\. Replace *aud* with **sub** and replace ** and ** with the name of your Kubernetes service account and the Kubernetes namespace that the account exists in\. + Change the line to look like the following line\. Replace *`EXAMPLED539D4633E53DE1B716D3041E`* with your cluster's OIDC provider ID and replace *region\-code* with the Region code that your cluster is in\. Replace *aud* with **sub** and replace *KUBERNETES\_ERVICE\_ACCOUNT\_NAMESPACE* and *KUBERNETES\_SERVICE\_ACCOUNT\_NAME* with the name of your Kubernetes service account and the Kubernetes namespace that the account exists in\. ``` - "oidc.eks..amazonaws.com/id/:sub": "system:serviceaccount::" + "oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E:sub": "system:serviceaccount:KUBERNETES_SERVICE_ACCOUNT_NAMESPACE:KUBERNETES_SERVICE_ACCOUNT_NAME" ``` **Note** If you don't have an existing Kubernetes service account, then you need to create one\. For more information, see [Configure Service Accounts for Pods](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) in the Kubernetes documentation\. For the service account to be able to use Kubernetes permissions, you must create a `Role`, or `ClusterRole` and then bind the role to the service account\. For more information, see [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) in the Kubernetes documentation\. When the [AWS VPC CNI plugin](pod-networking.md) is deployed, for example, the deployment manifest creates a service account, cluster role, and cluster role binding\. You can view the[manifest](https://raw.githubusercontent.com/aws/amazon-vpc-cni-k8s/release-1.10/config/v1.10/aws-k8s-cni.yaml) on GitHub\. @@ -148,15 +148,15 @@ If you don't have an existing Kubernetes service account, then you need to creat ACCOUNT_ID=$(aws sts get-caller-identity --query "Account" --output text) ``` -1. Set your OIDC identity provider to an environment variable with the following command\. Replace the *``* \(including *`<>`*\) with your own values\. +1. Set your OIDC identity provider to an environment variable with the following command\. Replace the *`example values`* with your own values\. **Important** You must use at least version 1\.22\.8 or 2\.3\.7 of the AWS CLI to receive the proper output from this command\. For more information, see [Installing the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) in the *AWS Command Line Interface User Guide*\. ``` - OIDC_PROVIDER=$(aws eks describe-cluster --name --query "cluster.identity.oidc.issuer" --output text | sed -e "s/^https:\/\///") + OIDC_PROVIDER=$(aws eks describe-cluster --name cluster-name --query "cluster.identity.oidc.issuer" --output text | sed -e "s/^https:\/\///") ``` -1. Copy the following code block to your computer and replace the *``* \(including *`<>`*\) with your own values\. +1. Copy the following code block to your computer and replace the *`example values`* with your own values\. ``` read -r -d '' TRUST_RELATIONSHIP <:" + "${OIDC_PROVIDER}:sub": "system:serviceaccount:my-namespace:my-service-account" } } } @@ -186,13 +186,13 @@ You must use at least version 1\.22\.8 or 2\.3\.7 of the AWS CLI to receive the 1. Run the following AWS CLI command to create the role\. ``` - aws iam create-role --role-name --assume-role-policy-document file://trust.json --description "" + aws iam create-role --role-name IAM_ROLE_NAME --assume-role-policy-document file://trust.json --description "IAM_ROLE_DESCRIPTION" ``` 1. Run the following command to attach your IAM policy to your role\. ``` - aws iam attach-role-policy --role-name --policy-arn= + aws iam attach-role-policy --role-name IAM_ROLE_NAME --policy-arn=IAM_POLICY_ARN ``` ------ \ No newline at end of file diff --git a/doc_source/create-public-private-vpc.md b/doc_source/creating-a-vpc.md similarity index 99% rename from doc_source/create-public-private-vpc.md rename to doc_source/creating-a-vpc.md index 0ca8eefa..3b253173 100644 --- a/doc_source/create-public-private-vpc.md +++ b/doc_source/creating-a-vpc.md @@ -1,4 +1,4 @@ -# Creating a VPC for your Amazon EKS cluster +# Creating a VPC for your Amazon EKS cluster Amazon Virtual Private Cloud \(Amazon VPC\) enables you to launch AWS resources into a virtual network that you've defined\. This virtual network closely resembles a traditional network that you'd operate in your own data center, with the benefits of using the scalable infrastructure of AWS\. For more information, see the [Amazon VPC User Guide](https://docs.aws.amazon.com/vpc/latest/userguide/) and [De\-mystifying cluster networking for Amazon EKS nodes](http://aws.amazon.com/blogs/containers/de-mystifying-cluster-networking-for-amazon-eks-worker-nodes)\. diff --git a/doc_source/delete-cluster.md b/doc_source/delete-cluster.md index 46af3472..1d8e410a 100644 --- a/doc_source/delete-cluster.md +++ b/doc_source/delete-cluster.md @@ -12,7 +12,7 @@ You can delete a cluster with `eksctl`, the AWS Management Console, or the AWS C **To delete an Amazon EKS cluster and nodes with `eksctl`** -This procedure requires `eksctl` version `0.76.0` or later\. You can check your version with the following command: +This procedure requires `eksctl` version `0.77.0` or later\. You can check your version with the following command: ``` eksctl version diff --git a/doc_source/eks-networking.md b/doc_source/eks-networking.md index 85d48a31..929f56c8 100644 --- a/doc_source/eks-networking.md +++ b/doc_source/eks-networking.md @@ -6,19 +6,19 @@ This chapter provides an overview of Amazon EKS networking\. The following diagr The following explanations help you understand how components of the diagram relate to each other and which topics in this guide and other AWS guides that you can reference for more information\. + **Amazon VPC and subnets** – All Amazon EKS resources are deployed to one Region in an existing subnet in an existing VPC\. For more information, see [VPCs and subnets](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html) in the Amazon VPC User Guide\. Each subnet exists in one Availability Zone\. The VPC and subnets must meet requirements such as the following: - + VPCs and subnets must be tagged appropriately, so that Kubernetes knows that it can use them for deploying resources, such as load balancers\. For more information, see [Subnet tagging](network_reqs.md#vpc-subnet-tagging)\. If you deploy the VPC using an Amazon EKS provided [AWS CloudFormation template](create-public-private-vpc.md#create-vpc) or using `eksctl`, then the VPC and subnets are tagged appropriately for you\. + + VPCs and subnets must be tagged appropriately, so that Kubernetes knows that it can use them for deploying resources, such as load balancers\. For more information, see [Subnet tagging](network_reqs.md#vpc-subnet-tagging)\. If you deploy the VPC using an Amazon EKS provided [AWS CloudFormation template](creating-a-vpc.md#create-vpc) or using `eksctl`, then the VPC and subnets are tagged appropriately for you\. + A subnet may or may not have internet access\. If a subnet does not have internet access, the pods deployed within it must be able to access other AWS services, such as Amazon ECR, to pull container images\. For more information about using subnets that don't have internet access, see [Private clusters](private-clusters.md)\. + Any public subnets that you use must be configured to auto\-assign public IP addresses for Amazon EC2 instances launched within them\. For more information, see [VPC IP addressing](network_reqs.md#vpc-cidr)\. + The nodes and control plane must be able to communicate over all ports through appropriately tagged [security groups](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)\. For more information, see [Amazon EKS security group considerations](sec-group-reqs.md)\. + You can implement a network segmentation and tenant isolation network policy\. Network policies are similar to AWS security groups in that you can create network ingress and egress rules\. Instead of assigning instances to a security group, you assign network policies to pods using pod selectors and labels\. For more information, see [Installing Calico on Amazon EKS](calico.md)\. - You can deploy a VPC and subnets that meet the Amazon EKS requirements through manual configuration, or by deploying the VPC and subnets using [`eksctl`](eksctl.md), or an Amazon EKS provided AWS CloudFormation template\. Both `eksctl` and the AWS CloudFormation template create the VPC and subnets with the required configuration\. For more information, see [Creating a VPC for your Amazon EKS cluster](create-public-private-vpc.md#create-vpc)\. + You can deploy a VPC and subnets that meet the Amazon EKS requirements through manual configuration, or by deploying the VPC and subnets using [`eksctl`](eksctl.md), or an Amazon EKS provided AWS CloudFormation template\. Both `eksctl` and the AWS CloudFormation template create the VPC and subnets with the required configuration\. For more information, see [Creating a VPC for your Amazon EKS cluster](creating-a-vpc.md#create-vpc)\. + **Amazon EKS control plane** – Deployed and managed by Amazon EKS in an Amazon EKS managed VPC\. When you create the cluster, Amazon EKS creates and manages network interfaces in your account that have `Amazon EKS ` in their description\. These network interfaces allow AWS Fargate and Amazon EC2 instances to communicate with the control plane\. By default, the control plane exposes a public endpoint so that clients and nodes can communicate with the cluster\. You can limit the internet client source IP addresses that can communicate with the public endpoint\. Alternatively, you can enable a private endpoint and disable the public endpoint or enable both the public and private endpoints\. To learn more about cluster endpoints, see [Amazon EKS cluster endpoint access control](cluster-endpoint.md)\. Clients in your on\-premises network or other VPCs can communicate with the public or private\-only endpoint, if you've configured connectivity between the VPC that the cluster is deployed to and the other networks\. For more information about connecting your VPC to other networks, see the AWS [Network\-to\-Amazon VPC connectivity options](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/network-to-amazon-vpc-connectivity-options.html) and [Amazon VPC\-to\-Amazon VPC connectivity options](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/amazon-vpc-to-amazon-vpc-connectivity-options.html) technical papers\. -+ **Amazon EC2 instances** – Each Amazon EC2 node is deployed to one subnet\. Each node is assigned a [private IP address](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#concepts-private-addresses) from a CIDR block assigned to the subnet\. If the subnets were created using one of the [Amazon EKS provided AWS CloudFormation templates](create-public-private-vpc.md#create-vpc), then nodes deployed to public subnets are automatically assigned a [public IP address](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#concepts-public-addresses) by the subnet\. Each node is deployed with the [Pod networking \(CNI\)](pod-networking.md) which, by default, assigns each pod a private IP address from the CIDR block assigned to the subnet that the node is in and adds the IP address as a secondary IP address to one of the [network interfaces](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) attached to the instance\. This AWS resource is referred to as a *network interface* in the AWS Management Console and the Amazon EC2 API\. Therefore, we use "network interface" in this documentation instead of "elastic network interface"\. The term "network interface" in this documentation always means "elastic network interface"\. ++ **Amazon EC2 instances** – Each Amazon EC2 node is deployed to one subnet\. Each node is assigned a [private IP address](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#concepts-private-addresses) from a CIDR block assigned to the subnet\. If the subnets were created using one of the [Amazon EKS provided AWS CloudFormation templates](creating-a-vpc.md#create-vpc), then nodes deployed to public subnets are automatically assigned a [public IP address](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#concepts-public-addresses) by the subnet\. Each node is deployed with the [Pod networking \(CNI\)](pod-networking.md) which, by default, assigns each pod a private IP address from the CIDR block assigned to the subnet that the node is in and adds the IP address as a secondary IP address to one of the [network interfaces](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) attached to the instance\. This AWS resource is referred to as a *network interface* in the AWS Management Console and the Amazon EC2 API\. Therefore, we use "network interface" in this documentation instead of "elastic network interface"\. The term "network interface" in this documentation always means "elastic network interface"\. You can change this behavior by assigning additional CIDR blocks to your VPC and enabling [CNI custom networking](cni-custom-network.md), which assigns IP addresses to pods from different subnets than the node is deployed to\. To use custom networking, you must enable it when you launch your nodes\. You can also associate unique security groups with some of the pods running on many Amazon EC2 instance types\. For more information, see [Security groups for pods](security-groups-for-pods.md)\. diff --git a/doc_source/eksctl.md b/doc_source/eksctl.md index 374240be..5122a6d3 100644 --- a/doc_source/eksctl.md +++ b/doc_source/eksctl.md @@ -45,7 +45,7 @@ The easiest way to get started with Amazon EKS and macOS is by installing `eksct eksctl version ``` **Note** - The `GitTag` version should be at least `0.76.0`\. If not, check your terminal output for any installation or upgrade errors, or manually download an archive of the release from [https://github\.com/weaveworks/eksctl/releases/download/v0\.76\.0/eksctl\_Darwin\_amd64\.tar\.gz](https://github.com/weaveworks/eksctl/releases/download/v0.76.0/eksctl_Darwin_amd64.tar.gz), extract `eksctl`, and then run it\. + The `GitTag` version should be at least `0.77.0`\. If not, check your terminal output for any installation or upgrade errors, or manually download an archive of the release from [https://github\.com/weaveworks/eksctl/releases/download/v0\.77\.0/eksctl\_Darwin\_amd64\.tar\.gz](https://github.com/weaveworks/eksctl/releases/download/v0.77.0/eksctl_Darwin_amd64.tar.gz), extract `eksctl`, and then run it\. ------ #### [ Linux ] @@ -70,7 +70,7 @@ The easiest way to get started with Amazon EKS and macOS is by installing `eksct eksctl version ``` **Note** -The `GitTag` version should be at least `0.76.0`\. If not, check your terminal output for any installation or upgrade errors, or replace the address in step 1 with `https://github.com/weaveworks/eksctl/releases/download/v0.76.0/eksctl_Linux_amd64.tar.gz` and complete steps 1\-3 again\. +The `GitTag` version should be at least `0.77.0`\. If not, check your terminal output for any installation or upgrade errors, or replace the address in step 1 with `https://github.com/weaveworks/eksctl/releases/download/v0.77.0/eksctl_Linux_amd64.tar.gz` and complete steps 1\-3 again\. ------ #### [ Windows ] @@ -97,6 +97,6 @@ The `GitTag` version should be at least `0.76.0`\. If not, check your terminal o eksctl version ``` **Note** - The `GitTag` version should be at least `0.76.0`\. If not, check your terminal output for any installation or upgrade errors, or manually download an archive of the release from [https://github\.com/weaveworks/eksctl/releases/download/v0\.76\.0/eksctl\_Windows\_amd64\.zip](https://github.com/weaveworks/eksctl/releases/download/v0.76.0/eksctl_Windows_amd64.zip), extract `eksctl`, and then run it\. + The `GitTag` version should be at least `0.77.0`\. If not, check your terminal output for any installation or upgrade errors, or manually download an archive of the release from [https://github\.com/weaveworks/eksctl/releases/download/v0\.77\.0/eksctl\_Windows\_amd64\.zip](https://github.com/weaveworks/eksctl/releases/download/v0.77.0/eksctl_Windows_amd64.zip), extract `eksctl`, and then run it\. ------ \ No newline at end of file diff --git a/doc_source/enable-iam-roles-for-service-accounts.md b/doc_source/enable-iam-roles-for-service-accounts.md index 348cfad5..53cd4883 100644 --- a/doc_source/enable-iam-roles-for-service-accounts.md +++ b/doc_source/enable-iam-roles-for-service-accounts.md @@ -17,33 +17,33 @@ You can create an OIDC provider for your cluster using `eksctl` or the AWS Manag View your cluster's OIDC provider URL\. ``` - aws eks describe-cluster --name --query "cluster.identity.oidc.issuer" --output text + aws eks describe-cluster --name cluster_name --query "cluster.identity.oidc.issuer" --output text ``` Example output: ``` - https://oidc.eks.us-west-2.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E + https://oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E ``` - List the IAM OIDC providers in your account\. Replace *``* \(including *`<>`*\) with the value returned from the previous command\. + List the IAM OIDC providers in your account\. Replace *`EXAMPLED539D4633E53DE1B716D3041E`* with the value returned from the previous command\. ``` - aws iam list-open-id-connect-providers | grep + aws iam list-open-id-connect-providers | grep EXAMPLED539D4633E53DE1B716D3041E ``` Example output ``` - "Arn": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-west-2.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E" + "Arn": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E" ``` If output is returned from the previous command, then you already have a provider for your cluster\. If no output is returned, then you must create an IAM OIDC provider\. -1. Create an IAM OIDC identity provider for your cluster with the following command\. Replace `` \(including `<>`\) with your own value\. +1. Create an IAM OIDC identity provider for your cluster with the following command\. Replace *cluster\_name* with your own value\. ``` - eksctl utils associate-iam-oidc-provider --cluster --approve + eksctl utils associate-iam-oidc-provider --cluster cluster_name --approve ``` ------ diff --git a/doc_source/external-snat.md b/doc_source/external-snat.md index 9b6a853d..c3bfb148 100644 --- a/doc_source/external-snat.md +++ b/doc_source/external-snat.md @@ -15,6 +15,6 @@ If the internet or devices in other private IP address spaces need to communicat kubectl set env daemonset -n kube-system aws-node AWS_VPC_K8S_CNI_EXTERNALSNAT=true ``` -After external SNAT is enabled, the CNI plugin doesn't translate a pod's private IP address to the primary private IP address assigned to the primary network interface of the Amazon EC2 instance node that the pod is running on when traffic is destined for an address outside of the VPC\. Traffic from the pod to the internet is externally translated to and from the public IP address of the NAT device and routed to and from the internet by an internet gateway, as shown in the following picture\. +After external SNAT is enabled, the CNI plugin doesn't translate a pod's private IP address to the primary private IP address assigned to the primary network interface of the Amazon EC2 instance node that the pod is running on when traffic is destined for an address outside of the VPC\. Traffic from the pod's private IP address is translated by a NAT device to the public IP address of the NAT device and routed to and from the internet by an internet gateway, as shown in the following picture\. ![\[Image NOT FOUND\]](http://docs.aws.amazon.com/eks/latest/userguide/images/SNAT-disabled.jpg) \ No newline at end of file diff --git a/doc_source/fargate-getting-started.md b/doc_source/fargate-getting-started.md index 4b508a91..bb5ca971 100644 --- a/doc_source/fargate-getting-started.md +++ b/doc_source/fargate-getting-started.md @@ -58,7 +58,7 @@ If you created your cluster with `eksctl` using the `--fargate` option, then a F You can create a Fargate profile using `eksctl` or the AWS Management Console\. -This procedure requires `eksctl` version `0.76.0` or later\. You can check your version with the following command: +This procedure requires `eksctl` version `0.77.0` or later\. You can check your version with the following command: ``` eksctl version diff --git a/doc_source/fargate-profile.md b/doc_source/fargate-profile.md index af200cc9..b2053da0 100644 --- a/doc_source/fargate-profile.md +++ b/doc_source/fargate-profile.md @@ -30,7 +30,7 @@ The following components are contained in a Fargate profile\. This topic helps you to create a Fargate profile\. AWS Fargate with Amazon EKS is available in all Amazon EKS Regions except China \(Beijing\), China \(Ningxia\), AWS GovCloud \(US\-East\), and AWS GovCloud \(US\-West\)\.\. You also must have created a pod execution role to use for your Fargate profile\. For more information, see [Pod execution role](pod-execution-role.md)\. Pods that are running on Fargate are only supported on private subnets \(with [NAT gateway](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) access to AWS services, but not a direct route to an Internet Gateway\), so your cluster's VPC must have private subnets available\. You can create a profile with `eksctl` or the AWS Management Console\. Select the tab with the name of the tool that you want to create your Fargate profile with\. -This procedure requires `eksctl` version `0.76.0` or later\. You can check your version with the following command: +This procedure requires `eksctl` version `0.77.0` or later\. You can check your version with the following command: ``` eksctl version diff --git a/doc_source/fsx-csi.md b/doc_source/fsx-csi.md index 4a5fa5af..2fe5b728 100644 --- a/doc_source/fsx-csi.md +++ b/doc_source/fsx-csi.md @@ -15,7 +15,7 @@ You must have: + Version 1\.22\.8 or later of the AWS CLI installed\. You can check your currently\-installed version with the `aws --version` command\. To install or upgrade the AWS CLI, see [Installing the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)\. + An existing Amazon EKS cluster\. If you don't currently have a cluster, see [Getting started with Amazon EKS](getting-started.md) to create one\. + An existing IAM OpenID Connect \(OIDC\) provider for your cluster\. To determine whether you already have one, or to create one, see [Create an IAM OIDC provider for your cluster](enable-iam-roles-for-service-accounts.md)\. -+ Version 0\.76\.0 or later of `eksctl` installed\. You can check your currently\-installed version with the `eksctl version` command\. To install or upgrade `eksctl`, see [Installing or upgrading `eksctl`](eksctl.md#installing-eksctl)\. ++ Version 0\.77\.0 or later of `eksctl` installed\. You can check your currently\-installed version with the `eksctl version` command\. To install or upgrade `eksctl`, see [Installing or upgrading `eksctl`](eksctl.md#installing-eksctl)\. + The latest version of `kubectl` installed that aligns to your cluster version\. You can check your currently\-installed version with the `kubectl version --short --client` command\. For more information, see [Installing `kubectl`](install-kubectl.md)\. **To deploy the FSx for Lustre CSI driver to an Amazon EKS cluster** diff --git a/doc_source/getting-started-console.md b/doc_source/getting-started-console.md index fc5a627f..fad12945 100644 --- a/doc_source/getting-started-console.md +++ b/doc_source/getting-started-console.md @@ -324,7 +324,7 @@ After you've finished with the cluster and nodes that you created for this tutor ## Next steps The following documentation topics help you to extend the functionality of your cluster\. -+ The IAM entity \(user or role\) that created the cluster is the only IAM user can make calls to the Kubernetes API server using `kubectl`\. If you want other users to have access to your cluster, see [Managing users or IAM roles for your cluster](add-user-role.md)\. ++ The IAM entity \(user or role\) that created the cluster is the only IAM user can make calls to the Kubernetes API server using `kubectl`\. If you want other users to have access to your cluster, see [Enabling IAM user and role access to your cluster](add-user-role.md)\. + Deploy a [sample application](sample-deployment.md) to your cluster\. + Before deploying a cluster for production use, we recommend familiarizing yourself with all of the settings for [clusters](create-cluster.md) and [nodes](eks-compute.md)\. Some settings, such as enabling SSH access to Amazon EC2 nodes must be made when the cluster is created\. + To increase security for your cluster, [configure the Amazon VPC Container Networking Interface plugin to use IAM roles for service accounts](cni-iam-role.md)\. \ No newline at end of file diff --git a/doc_source/getting-started-eksctl.md b/doc_source/getting-started-eksctl.md index b4435cb2..aa1923f6 100644 --- a/doc_source/getting-started-eksctl.md +++ b/doc_source/getting-started-eksctl.md @@ -8,7 +8,7 @@ The procedures in this guide create several resources for you automatically that Before starting this tutorial, you must install and configure the following tools and resources that you need to create and manage an Amazon EKS cluster\. + **`kubectl`** – A command line tool for working with Kubernetes clusters\. This guide requires that you use version 1\.21 or later\. For more information, see [Installing `kubectl`](install-kubectl.md)\. -+ **`eksctl`** – A command line tool for working with EKS clusters that automates many individual tasks\. This guide requires that you use version 0\.76\.0 or later\. For more information, see [The `eksctl` command line utility](eksctl.md)\. ++ **`eksctl`** – A command line tool for working with EKS clusters that automates many individual tasks\. This guide requires that you use version 0\.77\.0 or later\. For more information, see [The `eksctl` command line utility](eksctl.md)\. + **Required IAM permissions** – The IAM security principal that you're using must have permissions to work with Amazon EKS IAM roles and service linked roles, AWS CloudFormation, and a VPC and related resources\. For more information, see [Actions, resources, and condition keys for Amazon Elastic Container Service for Kubernetes](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html) and [Using service\-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html) in the IAM User Guide\. You must complete all steps in this guide as the same user\. ## Step 1: Create your Amazon EKS cluster and nodes @@ -134,6 +134,6 @@ eksctl delete cluster --name my-cluster --region region-code The following documentation topics help you to extend the functionality of your cluster\. + Deploy a [sample application](sample-deployment.md) to your cluster\. -+ The IAM entity \(user or role\) that created the cluster is the only IAM user can make calls to the Kubernetes API server using `kubectl`\. If you want other users to have access to your cluster, see [Managing users or IAM roles for your cluster](add-user-role.md)\. ++ The IAM entity \(user or role\) that created the cluster is the only IAM user can make calls to the Kubernetes API server using `kubectl`\. If you want other users to have access to your cluster, see [Enabling IAM user and role access to your cluster](add-user-role.md)\. + Before deploying a cluster for production use, we recommend familiarizing yourself with all of the settings for [clusters](create-cluster.md) and [nodes](eks-compute.md)\. Some settings, such as enabling SSH access to Amazon EC2 nodes must be made when the cluster is created\. + To increase security for your cluster, [configure the Amazon VPC Container Networking Interface plugin to use IAM roles for service accounts](cni-iam-role.md)\. \ No newline at end of file diff --git a/doc_source/horizontal-pod-autoscaler.md b/doc_source/horizontal-pod-autoscaler.md index 4d20c81a..271ba14b 100644 --- a/doc_source/horizontal-pod-autoscaler.md +++ b/doc_source/horizontal-pod-autoscaler.md @@ -67,7 +67,7 @@ This example is based on the [Horizontal pod autoscaler walkthrough](https://kub 1. To watch the deployment scale out, periodically run the following command in a separate terminal from the terminal that you ran the previous step in\. ``` - kubectl get hpa + kubectl get hpa php-apache ``` Output: @@ -77,7 +77,7 @@ This example is based on the [Horizontal pod autoscaler walkthrough](https://kub php-apache Deployment/php-apache 250%/50% 1 10 5 4m44s ``` - As long as actual CPU percentage is higher than the target percentage, then the replica count increases, up to 10\. In this case, it's `250%`, so the number of `REPLICAS` continues to increase\. + It may take over a minute for the replica count to increase\. As long as actual CPU percentage is higher than the target percentage, then the replica count increases, up to 10\. In this case, it's `250%`, so the number of `REPLICAS` continues to increase\. **Note** It may take a few minutes before you see the replica count reach its maximum\. If only 6 replicas, for example, are necessary for the CPU load to remain at or under 50%, then the load won't scale beyond 6 replicas\. diff --git a/doc_source/iam-roles-for-service-accounts-technical-overview.md b/doc_source/iam-roles-for-service-accounts-technical-overview.md index 6027d82b..52f15f08 100644 --- a/doc_source/iam-roles-for-service-accounts-technical-overview.md +++ b/doc_source/iam-roles-for-service-accounts-technical-overview.md @@ -18,12 +18,12 @@ In IAM, you create an IAM role with a trust relationship that is scoped to your { "Effect": "Allow", "Principal": { - "Federated": "arn:aws:iam:::oidc-provider/" + "Federated": "arn:aws:iam::ACCOUNT_ID:oidc-provider/OIDC_PROVIDER" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { - ":sub": "system:serviceaccount::" + "OIDC_PROVIDER:sub": "system:serviceaccount:SERVICE_ACCOUNT_NAMESPACE:SERVICE_ACCOUNT_NAME" } } } @@ -39,12 +39,12 @@ In IAM, you create an IAM role with a trust relationship that is scoped to your { "Effect": "Allow", "Principal": { - "Federated": "arn:aws:iam:::oidc-provider/" + "Federated": "arn:aws:iam::ACCOUNT_ID:oidc-provider/OIDC_PROVIDER" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringLike": { - ":sub": "system:serviceaccount::*" + "OIDC_PROVIDER:sub": "system:serviceaccount:SERVICE_ACCOUNT_NAMESPACE:*" } } } @@ -61,7 +61,7 @@ apiVersion: v1 kind: ServiceAccount metadata: annotations: - eks.amazonaws.com/role-arn: arn:aws:iam:::role/ + eks.amazonaws.com/role-arn: arn:aws:iam::ACCOUNT_ID:role/IAM_ROLE_NAME ``` ## Pod configuration @@ -69,7 +69,7 @@ metadata: The [Amazon EKS Pod Identity Webhook](https://github.com/aws/amazon-eks-pod-identity-webhook) on the cluster watches for pods that are associated with service accounts with this annotation and applies the following environment variables to them\. ``` -AWS_ROLE_ARN=arn:aws:iam:::role/ +AWS_ROLE_ARN=arn:aws:iam::ACCOUNT_ID:role/IAM_ROLE_NAME AWS_WEB_IDENTITY_TOKEN_FILE=/var/run/secrets/eks.amazonaws.com/serviceaccount/token ``` @@ -90,19 +90,19 @@ Providing this security context is not required for 1\.19 or later clusters\. apiVersion: apps/v1 kind: Deployment metadata: - name: + name: my-app spec: template: metadata: labels: - app: + app: my-app spec: - serviceAccountName: + serviceAccountName: my-app containers: - - name: - image: :latest + - name: my-app + image: my-app:latest securityContext: - fsGroup: <1337> + fsGroup: 1337 ... ``` @@ -122,7 +122,7 @@ apiVersion: v1 kind: ServiceAccount metadata: annotations: - eks.amazonaws.com/role-arn: arn:aws:iam:::role/ + eks.amazonaws.com/role-arn: arn:aws:iam::ACCOUNT_B_ID:role/IAM_ROLE_NAME ``` **Example : Use chained `AssumeRole` operations** @@ -154,7 +154,7 @@ Account A creates a role with a trust policy that gets credentials from the iden { "Effect": "Allow", "Principal": { - "Federated": "arn:aws:iam::111111111111:oidc-provider/oidc.eks..amazonaws.com/id/EXAMPLEC061A78C479E31025A21AC4CDE191335D05820BE5CE" + "Federated": "arn:aws:iam::111111111111:oidc-provider/oidc.eks.region-code.amazonaws.com/id/EXAMPLEC061A78C479E31025A21AC4CDE191335D05820BE5CE" }, "Action": "sts:AssumeRoleWithWebIdentity" } diff --git a/doc_source/index.md b/doc_source/index.md index 14b5e3b0..4683cef8 100644 --- a/doc_source/index.md +++ b/doc_source/index.md @@ -75,7 +75,7 @@ Amazon's trademarks and trade dress may not be used in + [Amazon FSx for Lustre CSI driver](fsx-csi.md) + [Amazon FSx for NetApp ONTAP CSI driver](fsx-ontap.md) + [Amazon EKS networking](eks-networking.md) - + [Creating a VPC for your Amazon EKS cluster](create-public-private-vpc.md) + + [Creating a VPC for your Amazon EKS cluster](creating-a-vpc.md) + [Cluster VPC considerations](network_reqs.md) + [Amazon EKS security group considerations](sec-group-reqs.md) + [Pod networking (CNI)](pod-networking.md) @@ -107,7 +107,7 @@ Amazon's trademarks and trade dress may not be used in + [Machine learning training using Elastic Fabric Adapter](node-efa.md) + [Machine learning inference using AWS Inferentia](inferentia-support.md) + [Cluster authentication](managing-auth.md) - + [Managing users or IAM roles for your cluster](add-user-role.md) + + [Enabling IAM user and role access to your cluster](add-user-role.md) + [Authenticating users for your cluster from an OpenID Connect identity provider](authenticate-oidc-identity-provider.md) + [Create a kubeconfig for Amazon EKS](create-kubeconfig.md) + [Installing aws-iam-authenticator](install-aws-iam-authenticator.md) diff --git a/doc_source/launch-node-bottlerocket.md b/doc_source/launch-node-bottlerocket.md index e9653f64..d6f2c766 100644 --- a/doc_source/launch-node-bottlerocket.md +++ b/doc_source/launch-node-bottlerocket.md @@ -21,7 +21,7 @@ Bottlerocket images don't come with an SSH server or a shell\. You can use out\- **To launch Bottlerocket nodes using `eksctl`** -This procedure requires `eksctl` version `0.76.0` or later\. You can check your version with the following command: +This procedure requires `eksctl` version `0.77.0` or later\. You can check your version with the following command: ``` eksctl version diff --git a/doc_source/launch-windows-workers.md b/doc_source/launch-windows-workers.md index ef4b9a25..d1752d98 100644 --- a/doc_source/launch-windows-workers.md +++ b/doc_source/launch-windows-workers.md @@ -14,7 +14,7 @@ You can launch self\-managed Windows nodes with `eksctl` or the AWS Management C **To launch self\-managed Windows nodes using `eksctl`** -This procedure requires that you have installed `eksctl`, and that your `eksctl` version is at least `0.76.0`\. You can check your version with the following command: +This procedure requires that you have installed `eksctl`, and that your `eksctl` version is at least `0.77.0`\. You can check your version with the following command: ``` eksctl version @@ -66,7 +66,7 @@ To see the available options for `eksctl` commands, enter the following command\ **Prerequisites** + An existing Amazon EKS cluster and a Linux node group\. If you don't have these resources, we recommend that you follow one of our [Getting started with Amazon EKS](getting-started.md) guides to create them\. The guides provide a complete walkthrough for how to create an Amazon EKS cluster with Linux nodes\. -+ An existing VPC and security group that meet the requirements for an Amazon EKS cluster\. For more information, see [Cluster VPC considerations](network_reqs.md) and [Amazon EKS security group considerations](sec-group-reqs.md)\. The [Getting started with Amazon EKS](getting-started.md) guide creates a VPC that meets the requirements\. Alternatively, you can also follow [Creating a VPC for your Amazon EKS cluster](create-public-private-vpc.md) to create one manually\. ++ An existing VPC and security group that meet the requirements for an Amazon EKS cluster\. For more information, see [Cluster VPC considerations](network_reqs.md) and [Amazon EKS security group considerations](sec-group-reqs.md)\. The [Getting started with Amazon EKS](getting-started.md) guide creates a VPC that meets the requirements\. Alternatively, you can also follow [](creating-a-vpc.md) to create one manually\. + An existing Amazon EKS cluster that uses a VPC and security group that meet the requirements of an Amazon EKS cluster\. For more information, see [Creating an Amazon EKS cluster](create-cluster.md)\. If you have subnets in the AWS Region where you have AWS Outposts, AWS Wavelength, or AWS Local Zones enabled, those subnets must not have been passed in when you created the cluster\. **Step 1: To launch self\-managed Windows nodes using the AWS Management Console** @@ -88,7 +88,7 @@ To see the available options for `eksctl` commands, enter the following command\ + **ClusterName**: Enter the name that you used when you created your Amazon EKS cluster\. **Important** This name must exactly match the name that you used in [Step 1: Create your Amazon EKS cluster](getting-started-console.md#eks-create-cluster)\. Otherwise, your nodes can't join the cluster\. - + **ClusterControlPlaneSecurityGroup**: Choose the security group from the AWS CloudFormation output that you generated when you created your [VPC](create-public-private-vpc.md)\. + + **ClusterControlPlaneSecurityGroup**: Choose the security group from the AWS CloudFormation output that you generated when you created your [VPC](creating-a-vpc.md)\. The following steps show one method to retrieve the applicable group\. @@ -116,11 +116,11 @@ The supported instance types for the latest version of the [Amazon VPC CNI plugi If you don't provide a key pair here, the AWS CloudFormation stack creation fails\. + **BootstrapArguments**: Specify any optional arguments to pass to the node bootstrap script, such as extra `kubelet` arguments using `-KubeletExtraArgs`\. + **DisableIMDSv1**: Each node supports the Instance Metadata Service Version 1 \(IMDSv1\) and IMDSv2 by default\. However, you can disable IMDSv1\. Select **true** if you don't want any nodes in the node group, or any pods scheduled on the nodes in the node group to use IMDSv1\. For more information about IMDS, see [Configuring the instance metadata service](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html)\. - + **VpcId**: Select the ID for the [VPC](create-public-private-vpc.md) that you created\. - + **NodeSecurityGroups**: Select the security group that was created for your Linux node group when you created your [VPC](create-public-private-vpc.md)\. If your Linux nodes have more than one security group attached to them, specify all of them here\. This for, for example, if the Linux node group was created with `eksctl`\. - + **Subnets**: Choose the subnets that you created\. If you created your VPC using the steps described at [Creating a VPC for your Amazon EKS cluster](create-public-private-vpc.md), then specify only the private subnets within the VPC for your nodes to launch into\. + + **VpcId**: Select the ID for the [VPC](creating-a-vpc.md) that you created\. + + **NodeSecurityGroups**: Select the security group that was created for your Linux node group when you created your [VPC](creating-a-vpc.md)\. If your Linux nodes have more than one security group attached to them, specify all of them here\. This for, for example, if the Linux node group was created with `eksctl`\. + + **Subnets**: Choose the subnets that you created\. If you created your VPC using the steps described at [Creating a VPC for your Amazon EKS cluster](creating-a-vpc.md), then specify only the private subnets within the VPC for your nodes to launch into\. **Important** -If any of the subnets are public subnets, then they must have the automatic public IP address assignment setting enabled\. If the setting isn't enabled for the public subnet, then any nodes that you deploy to that public subnet won't be assigned a public IP address and won't be able to communicate with the cluster or other AWS services\. If the subnet was deployed before March 26, 2020 using either of the [Amazon EKS AWS CloudFormation VPC templates](create-public-private-vpc.md), or by using `eksctl`, then automatic public IP address assignment is disabled for public subnets\. For information about how to enable public IP address assignment for a subnet, see [ Modifying the Public IPv4 Addressing Attribute for Your Subnet](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip)\. If the node is deployed to a private subnet, then it's able to communicate with the cluster and other AWS services through a NAT gateway\. +If any of the subnets are public subnets, then they must have the automatic public IP address assignment setting enabled\. If the setting isn't enabled for the public subnet, then any nodes that you deploy to that public subnet won't be assigned a public IP address and won't be able to communicate with the cluster or other AWS services\. If the subnet was deployed before March 26, 2020 using either of the [Amazon EKS AWS CloudFormation VPC templates](creating-a-vpc.md), or by using `eksctl`, then automatic public IP address assignment is disabled for public subnets\. For information about how to enable public IP address assignment for a subnet, see [ Modifying the Public IPv4 Addressing Attribute for Your Subnet](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip)\. If the node is deployed to a private subnet, then it's able to communicate with the cluster and other AWS services through a NAT gateway\. If the subnets don't have internet access, then make sure that you're aware of the considerations and extra steps in [Private clusters](private-clusters.md)\. If you're deploying the nodes in a 1\.18 or earlier cluster, make sure that the subnets you select are tagged with the cluster name\. Replace *my\-cluster* \(including *<>*\) with the name of your cluster and then run the following command to see a list of the subnets currently tagged with your cluster name\. diff --git a/doc_source/launch-workers.md b/doc_source/launch-workers.md index 73db4af3..009f5dae 100644 --- a/doc_source/launch-workers.md +++ b/doc_source/launch-workers.md @@ -7,7 +7,7 @@ This topic describes how you can launch an Auto Scaling group of Linux nodes tha **Prerequisites** + An existing Amazon EKS cluster that was created using `eksctl`\. -+ `eksctl` version `0.76.0` or later\. For more information about installing or upgrading `eksctl`, see [Installing or upgrading `eksctl`](eksctl.md#installing-eksctl)\. ++ `eksctl` version `0.77.0` or later\. For more information about installing or upgrading `eksctl`, see [Installing or upgrading `eksctl`](eksctl.md#installing-eksctl)\. **To launch self\-managed Linux nodes using `eksctl`** @@ -58,7 +58,7 @@ You must create the node group with a config file that specifies the subnets and #### [ AWS Management Console ] **Prerequisites** -+ An existing VPC and security group that meet the requirements for an Amazon EKS cluster\. For more information, see [Cluster VPC considerations](network_reqs.md) and [Amazon EKS security group considerations](sec-group-reqs.md)\. The [Getting started with Amazon EKS](getting-started.md) guide creates a VPC that meets the requirements, or you can also follow [Creating a VPC for your Amazon EKS cluster](create-public-private-vpc.md) to create one manually\. ++ An existing VPC and security group that meet the requirements for an Amazon EKS cluster\. For more information, see [Cluster VPC considerations](network_reqs.md) and [Amazon EKS security group considerations](sec-group-reqs.md)\. The [Getting started with Amazon EKS](getting-started.md) guide creates a VPC that meets the requirements, or you can also follow [Creating a VPC for your Amazon EKS cluster](creating-a-vpc.md) to create one manually\. + An existing Amazon EKS cluster that uses a VPC and security group that meet the requirements of an Amazon EKS cluster\. For more information, see [Creating an Amazon EKS cluster](create-cluster.md)\. If you have subnets in the AWS Region where you have AWS Outposts, AWS Wavelength, or AWS Local Zones enabled, those subnets must not have been passed in when you created the cluster\. **Step 1: To launch self\-managed Linux nodes using the AWS Management Console** @@ -80,7 +80,7 @@ You must create the node group with a config file that specifies the subnets and 1. On the **Specify stack details** page, enter the following parameters accordingly: + **Stack name**: Choose a stack name for your AWS CloudFormation stack\. For example, you can call it **cluster\-name\-nodes**\. + **ClusterName**: Enter the name that you used when you created your Amazon EKS cluster\. This name must equal the cluster name or your nodes can't join the cluster\. - + **ClusterControlPlaneSecurityGroup**: Choose the **SecurityGroups** value from the AWS CloudFormation output that you generated when you created your [VPC](create-public-private-vpc.md)\. + + **ClusterControlPlaneSecurityGroup**: Choose the **SecurityGroups** value from the AWS CloudFormation output that you generated when you created your [VPC](creating-a-vpc.md)\. The following steps show one operation to retrieve the applicable group\. @@ -110,10 +110,10 @@ The Amazon EKS node AMI is based on Amazon Linux 2\. You can track security or p If you don't provide a key pair here, the AWS CloudFormation stack creation fails\. + **BootstrapArguments**: Specify any optional arguments to pass to the node bootstrap script, such as extra `kubelet` arguments\. For more information, view the [bootstrap script usage information](https://github.com/awslabs/amazon-eks-ami/blob/master/files/bootstrap.sh) on GitHub\. To deploy a node group that allows your instance to assign a significantly higher number of IP addresses to pods, assign IP addresses to pods from a different CIDR block than that of the instance, enable the `containerd` runtime, or deploy a private cluster without outbound internet access, see [Increase the amount of available IP addresses for your Amazon EC2 nodes](cni-increase-ip-addresses.md), [CNI custom networking](cni-custom-network.md), [Enable the `containerd` runtime bootstrap flag](eks-optimized-ami.md#containerd-bootstrap), and [Private clusters](private-clusters.md) for arguments to add here\. + **DisableIMDSv1**: By default, each node supports the Instance Metadata Service Version 1 \(IMDSv1\) and IMDSv2\. However, you can disable IMDSv1\. Select **true** if you don't want any nodes in the node group, or any pods scheduled on the nodes in the node group to use IMDSv1\. For more information about IMDS, see [Configuring the instance metadata service](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html)\. For more information about restricting access to it on your nodes, see [Restrict access to the instance profile assigned to the worker node](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)\. - + **VpcId**: Enter the ID for the [VPC](create-public-private-vpc.md) that you created\. - + **Subnets**: Choose the subnets that you created for your VPC\. If you created your VPC using the steps described in [Creating a VPC for your Amazon EKS cluster](create-public-private-vpc.md), then specify only the private subnets within the VPC for your nodes to launch into\. + + **VpcId**: Enter the ID for the [VPC](creating-a-vpc.md) that you created\. + + **Subnets**: Choose the subnets that you created for your VPC\. If you created your VPC using the steps described in [Creating a VPC for your Amazon EKS cluster](creating-a-vpc.md), then specify only the private subnets within the VPC for your nodes to launch into\. **Important** -If any of the subnets are public subnets, then they must have the automatic public IP address assignment setting enabled\. If the setting isn't enabled for the public subnet, then any nodes that you deploy to that public subnet won't be assigned a public IP address and won't be able to communicate with the cluster or other AWS services\. If the subnet was deployed before March 26, 2020 using either of the [Amazon EKS AWS CloudFormation VPC templates](create-public-private-vpc.md), or by using `eksctl`, then automatic public IP address assignment is disabled for public subnets\. For information about how to enable public IP address assignment for a subnet, see [ Modifying the Public IPv4 Addressing Attribute for Your Subnet](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip)\. If the node is deployed to a private subnet, then it's able to communicate with the cluster and other AWS services through a NAT gateway\. +If any of the subnets are public subnets, then they must have the automatic public IP address assignment setting enabled\. If the setting isn't enabled for the public subnet, then any nodes that you deploy to that public subnet won't be assigned a public IP address and won't be able to communicate with the cluster or other AWS services\. If the subnet was deployed before March 26, 2020 using either of the [Amazon EKS AWS CloudFormation VPC templates](creating-a-vpc.md), or by using `eksctl`, then automatic public IP address assignment is disabled for public subnets\. For information about how to enable public IP address assignment for a subnet, see [ Modifying the Public IPv4 Addressing Attribute for Your Subnet](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip)\. If the node is deployed to a private subnet, then it's able to communicate with the cluster and other AWS services through a NAT gateway\. If the subnets don't have internet access, make sure that you're aware of the considerations and extra steps in [Private clusters](private-clusters.md)\. If you're deploying the nodes in a 1\.18 or earlier cluster, make sure that the subnets you select are tagged with the cluster name\. Replace *my\-cluster* \(including *<>*\) with the name of your cluster\. Then, run the following command to see a list of the subnets currently tagged with your cluster name\. diff --git a/doc_source/managed-node-groups.md b/doc_source/managed-node-groups.md index 2247f1fa..837ec416 100644 --- a/doc_source/managed-node-groups.md +++ b/doc_source/managed-node-groups.md @@ -23,7 +23,7 @@ To add a managed node group to an existing cluster, see [Creating a managed node If you are running a stateful application across multiple Availability Zones that is backed by Amazon EBS volumes and using the Kubernetes [Cluster Autoscaler](autoscaling.md#cluster-autoscaler), you should configure multiple node groups, each scoped to a single Availability Zone\. In addition, you should enable the `--balance-similar-node-groups` feature\. + You can use a custom launch template for a greater level of flexibility and customization when deploying managed nodes\. If you deploy using a launch template, you can also use a custom AMI\. For more information, see [Launch template support](launch-templates.md)\. If you don't use a custom launch template when first creating a managed node group, there is an auto\-generated launch template\. Don't manually modify this auto\-generated template or errors occur\. + Amazon EKS follows the shared responsibility model for CVEs and security patches on managed node groups\. When managed nodes run an Amazon EKS optimized AMI, Amazon EKS is responsible for building patched versions of the AMI when bugs or issues are reported\. We can publish a fix\. However, you're responsible for deploying these patched AMI versions to your managed node groups\. When managed nodes run a custom AMI, you're responsible for building patched versions of the AMI when bugs or issues are reported and then deploying the AMI\. For more information, see [Updating a managed node group](update-managed-node-group.md)\. -+ Amazon EKS managed node groups can be launched in both public and private subnets\. If you launch a managed node group in a public subnet on or after April 22, 2020, the subnet must have `MapPublicIpOnLaunch` set to true for the instances to successfully join a cluster\. If the public subnet was created using `eksctl` or the [Amazon EKS vended AWS CloudFormation templates](create-public-private-vpc.md) on or after March 26, 2020, then this setting is already set to true\. If the public subnets were created before March 26, 2020, you must change the setting manually\. For more information, see [Modifying the public IPv4 addressing attribute for your subnet](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip)\. ++ Amazon EKS managed node groups can be launched in both public and private subnets\. If you launch a managed node group in a public subnet on or after April 22, 2020, the subnet must have `MapPublicIpOnLaunch` set to true for the instances to successfully join a cluster\. If the public subnet was created using `eksctl` or the [Amazon EKS vended AWS CloudFormation templates](creating-a-vpc.md) on or after March 26, 2020, then this setting is already set to true\. If the public subnets were created before March 26, 2020, you must change the setting manually\. For more information, see [Modifying the public IPv4 addressing attribute for your subnet](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip)\. + When using VPC endpoints in private subnets, you must create endpoints for `com.amazonaws.region.ecr.api`, `com.amazonaws.region.ecr.dkr`, and a gateway endpoint for Amazon S3\. For more information, see [Amazon ECR interface VPC endpoints \(AWS PrivateLink\)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html#ecr-setting-up-vpc-create)\. + Managed node groups can't be deployed on [AWS Outposts](eks-on-outposts.md) or in AWS Wavelength or AWS Local Zones\. + You can create multiple managed node groups within a single cluster\. For example, you can create one node group with the standard Amazon EKS optimized Amazon Linux 2 AMI for some workloads and another with the GPU variant for workloads that require GPU support\. diff --git a/doc_source/managing-auth.md b/doc_source/managing-auth.md index 1283f203..316ab398 100644 --- a/doc_source/managing-auth.md +++ b/doc_source/managing-auth.md @@ -8,7 +8,7 @@ Amazon EKS uses IAM to provide authentication to your Kubernetes cluster \(throu Amazon EKS uses the authentication token to make the `sts:GetCallerIdentity` call\. As a result, AWS CloudTrail events with the name `GetCallerIdentity` from the source `sts.amazonaws.com` can have Amazon EKS service IP addresses for their source IP address\. **Topics** -+ [Managing users or IAM roles for your cluster](add-user-role.md) ++ [Enabling IAM user and role access to your cluster](add-user-role.md) + [Authenticating users for your cluster from an OpenID Connect identity provider](authenticate-oidc-identity-provider.md) + [Create a `kubeconfig` for Amazon EKS](create-kubeconfig.md) + [Installing `aws-iam-authenticator`](install-aws-iam-authenticator.md) diff --git a/doc_source/migrate-stack.md b/doc_source/migrate-stack.md index fa9d77ca..dfc3bcdc 100644 --- a/doc_source/migrate-stack.md +++ b/doc_source/migrate-stack.md @@ -4,7 +4,7 @@ This topic describes how you can create a new node group, gracefully migrate you **To migrate your applications to a new node group with `eksctl`** -This procedure requires `eksctl` version `0.76.0` or later\. You can check your version with the following command: +This procedure requires `eksctl` version `0.77.0` or later\. You can check your version with the following command: ``` eksctl version diff --git a/doc_source/network-load-balancing.md b/doc_source/network-load-balancing.md index a410c097..aea111b2 100644 --- a/doc_source/network-load-balancing.md +++ b/doc_source/network-load-balancing.md @@ -19,10 +19,10 @@ Before you can load balance network traffic, you must meet the following require + **Key** – `kubernetes.io/cluster/cluster-name` + **Value** – `shared` or `owned` + Your public and private subnets must meet the following requirements, unless you explicitly specify subnet IDs as an annotation on a Service or Ingress object\. If you provision load balancers by explicitly specifying subnet IDs as an annotation on a Service or Ingress object, then Kubernetes and the AWS Load Balancer Controller use those subnets directly to create the load balancer and the following tags aren't required\. - + **Private subnets** – Must be tagged in the following format\. This is so that Kubernetes and the AWS Load Balancer Controller know that the subnets can be used for internal load balancers\. If you use `eksctl` or an Amazon EKS AWS AWS CloudFormation template to create your VPC after March 26, 2020, then the subnets are tagged appropriately when they're created\. For more information about the Amazon EKS AWS AWS CloudFormation VPC templates, see [Creating a VPC for your Amazon EKS cluster](create-public-private-vpc.md)\. + + **Private subnets** – Must be tagged in the following format\. This is so that Kubernetes and the AWS Load Balancer Controller know that the subnets can be used for internal load balancers\. If you use `eksctl` or an Amazon EKS AWS AWS CloudFormation template to create your VPC after March 26, 2020, then the subnets are tagged appropriately when they're created\. For more information about the Amazon EKS AWS AWS CloudFormation VPC templates, see [Creating a VPC for your Amazon EKS cluster](creating-a-vpc.md)\. + **Key** – `kubernetes.io/role/internal-elb` + **Value** – `1` - + **Public subnets** – Must be tagged in the following format\. This is so that Kubernetes knows to use only those subnets for external load balancers instead of choosing a public subnet in each Availability Zone \(based on the lexicographical order of the subnet IDs\)\. If you use `eksctl` or an Amazon EKS AWS CloudFormation template to create your VPC after March 26, 2020, then the subnets are tagged appropriately when they're created\. For more information about the Amazon EKS AWS CloudFormation VPC templates, see [Creating a VPC for your Amazon EKS cluster](create-public-private-vpc.md)\. + + **Public subnets** – Must be tagged in the following format\. This is so that Kubernetes knows to use only those subnets for external load balancers instead of choosing a public subnet in each Availability Zone \(based on the lexicographical order of the subnet IDs\)\. If you use `eksctl` or an Amazon EKS AWS CloudFormation template to create your VPC after March 26, 2020, then the subnets are tagged appropriately when they're created\. For more information about the Amazon EKS AWS CloudFormation VPC templates, see [Creating a VPC for your Amazon EKS cluster](creating-a-vpc.md)\. + **Key** – `kubernetes.io/role/elb` + **Value** – `1` diff --git a/doc_source/network_reqs.md b/doc_source/network_reqs.md index f9456e3d..5eb2560d 100644 --- a/doc_source/network_reqs.md +++ b/doc_source/network_reqs.md @@ -41,7 +41,7 @@ aws ec2 modify-subnet-attribute --map-public-ip-on-launch --subnet-id diff --git a/doc_source/node-efa.md b/doc_source/node-efa.md index 85269a01..258bed35 100644 --- a/doc_source/node-efa.md +++ b/doc_source/node-efa.md @@ -46,7 +46,7 @@ The following procedure helps you create a node group with a `p4d.24xlarge` back #### [ eksctl ] **Prerequisite** -`Eksctl` version 0\.76\.0 or later installed on your computer or AWS CloudShell\. To install or upgrade `eksctl`, see [The `eksctl` command line utility](eksctl.md)\. +`Eksctl` version 0\.77\.0 or later installed on your computer or AWS CloudShell\. To install or upgrade `eksctl`, see [The `eksctl` command line utility](eksctl.md)\. 1. Copy the following contents to a file named `efa-cluster.yaml`\. Replace the *example values* with your own\. You can replace *p4d\.24xlarge* with a different instance, but if you do, make sure that the values for `availabilityZones` are Availability Zones that were returned for the instance type in step 1\. diff --git a/doc_source/private-clusters.md b/doc_source/private-clusters.md index 0bd1f29f..e1af2540 100644 --- a/doc_source/private-clusters.md +++ b/doc_source/private-clusters.md @@ -23,7 +23,7 @@ The following requirements must be met to run Amazon EKS in a private cluster wi ``` For additional arguments, see [Amazon EKS optimized Windows AMI](eks-custom-ami-windows.md)\. -+ The `aws-auth` ConfigMap must be created from within the VPC\. For more information about create the `aws-auth` ConfigMap, see [Managing users or IAM roles for your cluster](add-user-role.md)\. ++ The `aws-auth` ConfigMap must be created from within the VPC\. For more information about create the `aws-auth` ConfigMap, see [Enabling IAM user and role access to your cluster](add-user-role.md)\. ## Considerations diff --git a/doc_source/security_iam_id-based-policy-examples.md b/doc_source/security_iam_id-based-policy-examples.md index 1b52a71a..a6f9f998 100644 --- a/doc_source/security_iam_id-based-policy-examples.md +++ b/doc_source/security_iam_id-based-policy-examples.md @@ -4,9 +4,9 @@ By default, IAM users and roles don't have permission to create or modify Amazon To learn how to create an IAM identity\-based policy using these example JSON policy documents, see [Creating policies on the JSON tab](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) in the *IAM User Guide*\. -When you create an Amazon EKS cluster, the AWS Identity and Access Management \(IAM\) entity user or role, such as a [federated user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) that creates the cluster, is automatically granted `system:masters` permissions in the cluster's role\-based access control \(RBAC\) configuration in the Amazon EKS control plane\. This IAM entity doesn't appear in any visible configuration, so make sure to keep track of which IAM entity originally created the cluster\. To grant additional AWS users or roles the ability to interact with your cluster, you must edit the `aws-auth` `ConfigMap` within Kubernetes\. +When you create an Amazon EKS cluster, the AWS Identity and Access Management \(IAM\) entity user or role, such as a [federated user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) that creates the cluster, is automatically granted `system:masters` permissions in the cluster's role\-based access control \(RBAC\) configuration in the Amazon EKS control plane\. This IAM entity doesn't appear in any visible configuration, so make sure to keep track of which IAM entity originally created the cluster\. To grant additional AWS users or roles the ability to interact with your cluster, you must edit the `aws-auth` `ConfigMap` within Kubernetes and create a Kubernetes `rolebinding` or `clusterrolebinding` with the name of a `group` that you specify in the `aws-auth` `ConfigMap`\. -For additional information about working with the ConfigMap, see [Managing users or IAM roles for your cluster](add-user-role.md)\. +For additional information about working with the ConfigMap, see [Enabling IAM user and role access to your cluster](add-user-role.md)\. **Topics** + [Policy best practices](#security_iam_service-with-iam-policy-best-practices) @@ -90,7 +90,7 @@ This example shows how you can create a policy that allows a user to [View nodes ``` **Important** -The policy must be attached to a user or role that is mapped to a Kubernetes user or group in the `aws-auth` configmap\. The user or group must be a `subject` in a `rolebinding` or `clusterrolebinding` that is bound to a Kubernetes `role` or `clusterrole` that has the necessary permissions to view the Kubernetes resources\. For more information about adding IAM users or roles to the `aws-auth` configmap, see [Managing users or IAM roles for your cluster](add-user-role.md)\. To create roles and role bindings, see [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) in the Kubernetes documentation\. You can download the following example manifests that create a `clusterrole` and `clusterrolebinding` or a `role` and `rolebinding`: +The policy must be attached to a user or role that is mapped to a Kubernetes user or group in the `aws-auth` configmap\. The user or group must be a `subject` in a `rolebinding` or `clusterrolebinding` that is bound to a Kubernetes `role` or `clusterrole` that has the necessary permissions to view the Kubernetes resources\. For more information about adding IAM users or roles to the `aws-auth` configmap, see [Enabling IAM user and role access to your cluster](add-user-role.md)\. To create roles and role bindings, see [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) in the Kubernetes documentation\. You can download the following example manifests that create a `clusterrole` and `clusterrolebinding` or a `role` and `rolebinding`: **View Kubernetes resources in all namespaces** – The group name in the file is `eks-console-dashboard-full-access-group`, which is the group that your IAM user or role needs to be mapped to in the `aws-auth` configmap\. You can change the name of the group before applying it to your cluster, if desired, and then map your IAM user or role to that group in the configmap\. To download the file, select the appropriate link for the Region that your cluster is in\. [All Regions other than Beijing and Ningxia China](https://amazon-eks.s3.us-west-2.amazonaws.com/docs/eks-console-full-access.yaml) [Beijing and Ningxia China Regions](https://amazon-eks.s3.cn-north-1.amazonaws.com.cn/docs/eks-console-full-access.yaml) diff --git a/doc_source/security_iam_service-with-iam.md b/doc_source/security_iam_service-with-iam.md index 5b35bba4..621f99e2 100644 --- a/doc_source/security_iam_service-with-iam.md +++ b/doc_source/security_iam_service-with-iam.md @@ -94,9 +94,9 @@ For a list of Amazon EKS condition keys, see [Condition Keys for Amazon Elastic To view examples of Amazon EKS identity\-based policies, see [Amazon EKS identity\-based policy examples](security_iam_id-based-policy-examples.md)\. -When you create an Amazon EKS cluster, the AWS Identity and Access Management \(IAM\) entity user or role, such as a [federated user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) that creates the cluster, is automatically granted `system:masters` permissions in the cluster's role\-based access control \(RBAC\) configuration in the Amazon EKS control plane\. This IAM entity doesn't appear in any visible configuration, so make sure to keep track of which IAM entity originally created the cluster\. To grant additional AWS users or roles the ability to interact with your cluster, you must edit the `aws-auth` `ConfigMap` within Kubernetes\. +When you create an Amazon EKS cluster, the AWS Identity and Access Management \(IAM\) entity user or role, such as a [federated user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) that creates the cluster, is automatically granted `system:masters` permissions in the cluster's role\-based access control \(RBAC\) configuration in the Amazon EKS control plane\. This IAM entity doesn't appear in any visible configuration, so make sure to keep track of which IAM entity originally created the cluster\. To grant additional AWS users or roles the ability to interact with your cluster, you must edit the `aws-auth` `ConfigMap` within Kubernetes and create a Kubernetes `rolebinding` or `clusterrolebinding` with the name of a `group` that you specify in the `aws-auth` `ConfigMap`\. -For additional information about working with the ConfigMap, see [Managing users or IAM roles for your cluster](add-user-role.md)\. +For additional information about working with the ConfigMap, see [Enabling IAM user and role access to your cluster](add-user-role.md)\. ## Amazon EKS resource\-based policies diff --git a/doc_source/specify-service-account-role.md b/doc_source/specify-service-account-role.md index 39721018..e6ae7c64 100644 --- a/doc_source/specify-service-account-role.md +++ b/doc_source/specify-service-account-role.md @@ -10,7 +10,7 @@ apiVersion: v1 kind: ServiceAccount metadata: annotations: - eks.amazonaws.com/role-arn: arn:aws:iam:::role/ + eks.amazonaws.com/role-arn: arn:aws:iam::ACCOUNT_ID:role/IAM_ROLE_NAME ``` **Prerequisites** @@ -21,37 +21,53 @@ metadata: **To annotate a service account with an IAM role** -1. Use the following command to annotate your service account with the ARN of the IAM role that you want to use with your service account\. Be sure to replace the `` \(including `<>`\) with your own\. +1. Use the following command to annotate your service account with the ARN of the IAM role that you want to use with your service account\. Be sure to replace the *example values* with your own\. ``` - kubectl annotate serviceaccount -n \ - eks.amazonaws.com/role-arn=arn:aws:iam:::role/ + kubectl annotate serviceaccount -n SERVICE_ACCOUNT_NAMESPACE SERVICE_ACCOUNT_NAME \ + eks.amazonaws.com/role-arn=arn:aws:iam::ACCOUNT_ID:role/IAM_ROLE_NAME ``` **Note** If you don't have an existing service account, then you need to create one\. For more information, see [Configure Service Accounts for Pods](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) in the Kubernetes documentation\. For the service account to be able to use Kubernetes permissions, you must create a `Role`, or `ClusterRole` and then bind the role to the service account\. For more information, see [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) in the Kubernetes documentation\. When the [AWS VPC CNI plugin](pod-networking.md) is deployed, for example, the deployment manifest creates a service account, cluster role, and cluster role binding\. You can view the[ manifest](https://raw.githubusercontent.com/aws/amazon-vpc-cni-k8s/release-1.10/config/v1.10/aws-k8s-cni.yaml) on GitHub to use as an example\. +1. \(Optional\) We recommend using the following command to add an additional annotation to your service account to use the AWS Security Token Service Regional endpoint, rather than the global endpoint\. AWS recommends using the Regional AWS STS endpoints instead of the global endpoint to reduce latency, build in redundancy, and increase session token validity\. The AWS Security Token Service must be active in the Region where the Pod is running and your application should have redundancy built in to pick a different Region in the event of a failure of the service in the Region\. For more information, see [Managing AWS STS in an AWS Region](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html) in the IAM User Guide\. + + To use this annotation, your cluster and platform version must be at or later than the following Kubernetes and Amazon EKS platform versions\. +[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/eks/latest/userguide/specify-service-account-role.html) + + ``` + kubectl annotate serviceaccount -n SERVICE_ACCOUNT_NAMESPACE SERVICE_ACCOUNT_NAME \ + eks.amazonaws.com/sts-regional-endpoints=true + ``` + 1. Delete and re\-create any existing pods that are associated with the service account to apply the credential environment variables\. The mutating web hook does not apply them to pods that are already running\. The following command deletes the existing the `aws-node` DaemonSet pods and deploys them with the service account annotation\. You can modify the namespace, deployment type, and label to update your specific pods\. ``` - kubectl delete pods -n -l + kubectl delete pods -n kube-system -l k8s-app=aws-node ``` 1. Confirm that the pods all restarted\. ``` - kubectl get pods -n -l + kubectl get pods -n kube-system -l k8s-app=aws-node ``` 1. Describe one of the pods and verify that the `AWS_WEB_IDENTITY_TOKEN_FILE` and `AWS_ROLE_ARN` environment variables exist\. ``` - kubectl exec -n kube-system env | grep AWS + kubectl exec -n kube-system aws-node-9rgzw env | grep AWS ``` Output: ``` AWS_VPC_K8S_CNI_LOGLEVEL=DEBUG - AWS_ROLE_ARN=arn:aws:iam:::role/ + AWS_ROLE_ARN=arn:aws:iam::ACCOUNT_ID:role/IAM_ROLE_NAME AWS_WEB_IDENTITY_TOKEN_FILE=/var/run/secrets/eks.amazonaws.com/serviceaccount/token + ``` + + If you added the annotation to your service account to use the AWS Security Token Service Regional endpoint, rather than the global endpoint, then the following line is also returned in the previous output\. + + ``` + AWS_STS_REGIONAL_ENDPOINTS: regional ``` \ No newline at end of file diff --git a/doc_source/troubleshooting.md b/doc_source/troubleshooting.md index a635e55f..f337ff7e 100644 --- a/doc_source/troubleshooting.md +++ b/doc_source/troubleshooting.md @@ -30,7 +30,7 @@ If you receive one of the following errors while running `kubectl` commands, t This could be because the cluster was created with one set of AWS credentials \(from an IAM user or role\), and `kubectl` is using a different set of credentials\. -When an Amazon EKS cluster is created, the IAM entity \(user or role\) that creates the cluster is added to the Kubernetes RBAC authorization table as the administrator \(with `system:masters` permissions\)\. Initially, only that IAM user can make calls to the Kubernetes API server using `kubectl` \. For more information, see [Managing users or IAM roles for your cluster](add-user-role.md)\. If you use the console to create the cluster, you must ensure that the same IAM user credentials are in the AWS SDK credential chain when you are running `kubectl` commands on your cluster\. +When an Amazon EKS cluster is created, the IAM entity \(user or role\) that creates the cluster is added to the Kubernetes RBAC authorization table as the administrator \(with `system:masters` permissions\)\. Initially, only that IAM user can make calls to the Kubernetes API server using `kubectl` \. For more information, see [Enabling IAM user and role access to your cluster](add-user-role.md)\. If you use the console to create the cluster, you must ensure that the same IAM user credentials are in the AWS SDK credential chain when you are running `kubectl` commands on your cluster\. If you install and configure the AWS CLI, you can configure the IAM credentials for your user\. For more information, see [Configuring the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html) in the *AWS Command Line Interface User Guide*\. @@ -43,7 +43,7 @@ aws eks update-kubeconfig \ --role-arn arn:aws:iam:::role/ ``` -To map an IAM user to a Kubernetes RBAC user, see [Managing users or IAM roles for your cluster](add-user-role.md)\. +To map an IAM user to a Kubernetes RBAC user, see [Enabling IAM user and role access to your cluster](add-user-role.md)\. ## `aws-iam-authenticator` Not found diff --git a/doc_source/troubleshooting_iam.md b/doc_source/troubleshooting_iam.md index e98cb169..684bf045 100644 --- a/doc_source/troubleshooting_iam.md +++ b/doc_source/troubleshooting_iam.md @@ -20,7 +20,7 @@ For more general information about IAM, see [Controlling access using policies]( You may see a console error message that says `Your current user or role does not have access to Kubernetes objects on this EKS cluster`\. Make sure that the IAM entity \(user or role\) that you’re signed into the AWS Management Console with meets all of the following requirements: + Has an IAM policy attached to it that includes the `eks:AccessKubernetesApi` action\. For an example IAM policy, see [View nodes and workloads for all clusters in the AWS Management Console](security_iam_id-based-policy-examples.md#policy_example3)\. If you're using the IAM policy visual editor in the AWS Management Console and you don't see the `eks:AccessKubernetesApi` **Permission** listed, edit the policy's JSON and add `eks:AccessKubernetesApi` to the list of `Action`s in the JSON\. -+ Has a mapping to a Kubernetes user or group in the `aws-auth` configmap\. For more information about adding IAM users or roles to the `aws-auth` configmap, see [Managing users or IAM roles for your cluster](add-user-role.md)\. If the user or role isn't mapped, the console error may include **Unauthorized: Verify you have access to the Kubernetes cluster**\. ++ Has a mapping to a Kubernetes user or group in the `aws-auth` configmap\. For more information about adding IAM users or roles to the `aws-auth` configmap, see [Enabling IAM user and role access to your cluster](add-user-role.md)\. If the user or role isn't mapped, the console error may include **Unauthorized: Verify you have access to the Kubernetes cluster**\. + The Kubernetes user or group that the IAM account or role is mapped to in the configmap must be a `subject` in a `rolebinding` or `clusterrolebinding` that is bound to a Kubernetes `role` or `clusterrole` that has the necessary permissions to view the Kubernetes resources\. If the user or group doesn't have the necessary permissions, the console error may include **Unauthorized: Verify you have access to the Kubernetes cluster**\. To create roles and bindings, see [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) in the Kubernetes documentation\. You can download the example manifests that create a `clusterrole` and `clusterrolebinding` or a `role` and `rolebinding` by following the instructions in the **Important** section of [View nodes and workloads for all clusters in the AWS Management Console](security_iam_id-based-policy-examples.md#policy_example3)\. ## aws\-auth ConfigMap does not grant access to the cluster diff --git a/doc_source/update-cluster.md b/doc_source/update-cluster.md index b3ddfc9b..1a4ea457 100644 --- a/doc_source/update-cluster.md +++ b/doc_source/update-cluster.md @@ -77,7 +77,7 @@ Updating your cluster to a newer version may overwrite custom configurations\. ------ #### [ eksctl ] - This procedure requires `eksctl` version `0.76.0` or later\. You can check your version with the following command: + This procedure requires `eksctl` version `0.77.0` or later\. You can check your version with the following command: ``` eksctl version diff --git a/doc_source/view-nodes.md b/doc_source/view-nodes.md index f890bab9..5f691b8c 100644 --- a/doc_source/view-nodes.md +++ b/doc_source/view-nodes.md @@ -7,7 +7,7 @@ The Amazon EKS console shows information about all of your cluster's nodes\. Thi The IAM user or IAM role that you sign into the AWS Management Console with must meet the following requirements\. + Have the `eks:AccessKubernetesApi` and other necessary IAM permissions to view nodes attached to it\. For an example IAM policy, see [View nodes and workloads for all clusters in the AWS Management Console](security_iam_id-based-policy-examples.md#policy_example3)\. + For nodes in connected clusters, the Amazon EKS Connector Service account can impersonate the IAM or role in the cluster\. This allows the eks\-connector to map the IAM user or role to a Kubernetes user\. -+ Is mapped to Kubernetes user or group in the `aws-auth` `configmap`\. For more information, see [Managing users or IAM roles for your cluster](add-user-role.md)\. ++ Is mapped to Kubernetes user or group in the `aws-auth` `configmap`\. For more information, see [Enabling IAM user and role access to your cluster](add-user-role.md)\. + The Kubernetes user or group that the IAM user or role is mapped to in the configmap must be bound to a Kubernetes `role` or `clusterrole`\. Additionally, this `role` or `clusterrole` must have the permissions to view the resources in the namespaces that you want to view\. For more information, see [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) in the Kubernetes documentation\. You can download the following example manifests that create a `clusterrole` and `clusterrolebinding` or a `role` and `rolebinding`: + **View Kubernetes resources in all namespaces** – The group name in the file is `eks-console-dashboard-full-access-group`\. It is the group that your IAM user or role must be mapped to in the `aws-auth` configmap\. You can change the name of the group before applying it to your cluster, if you want\. Then, you can map your IAM user or role to that group in the configmap\. To download the file, select the appropriate link for the AWS Region that your cluster is in\. + [All Regions other than Beijing and Ningxia China](https://amazon-eks.s3.us-west-2.amazonaws.com/docs/eks-console-full-access.yaml) diff --git a/doc_source/view-workloads.md b/doc_source/view-workloads.md index 6c6ef659..ad484141 100644 --- a/doc_source/view-workloads.md +++ b/doc_source/view-workloads.md @@ -9,7 +9,7 @@ You can use the Amazon EKS console to view information about the Kubernetes work The IAM user or IAM role that you sign into the AWS Management Console with must meet the following requirements\. + Has the `eks:AccessKubernetesApi` and other necessary IAM permissions to view workloads attached to it\. For an example IAM policy, see [View nodes and workloads for all clusters in the AWS Management Console](security_iam_id-based-policy-examples.md#policy_example3) \. + For nodes in connected clusters, the [Amazon EKS Connector Service](https://docs.aws.amazon.com/eks/latest/userguide/eks-connector.html) account should be able to impersonate the IAM or role in the cluster\. This allows the eks\-connector to map the IAM user or role to a Kubernetes user\. -+ Is mapped to Kubernetes user or group in the `aws-auth` `configmap`\. For more information, see [Managing users or IAM roles for your cluster](add-user-role.md)\. ++ Is mapped to Kubernetes user or group in the `aws-auth` `configmap`\. For more information, see [Enabling IAM user and role access to your cluster](add-user-role.md)\. + The Kubernetes user or group that the IAM user or role is mapped to in the configmap must be bound to a Kubernetes `role` or `clusterrole` that has permissions to view the resources in the namespaces that you want to view\. For more information, see [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) in the Kubernetes documentation\. You can download the following example manifests that create a `clusterrole` and `clusterrolebinding` or a `role` and `rolebinding`: + **View Kubernetes resources in all namespaces** – The group name in the file is `eks-console-dashboard-full-access-group`, which is the group that your IAM user or role needs to be mapped to in the `aws-auth` configmap\. You can change the name of the group before applying it to your cluster, if desired, and then map your IAM user or role to that group in the configmap\. To download the file, select the appropriate link for the Region that your cluster is in\. + [All Regions other than Beijing and Ningxia China](https://amazon-eks.s3.us-west-2.amazonaws.com/docs/eks-console-full-access.yaml) diff --git a/doc_source/windows-support.md b/doc_source/windows-support.md index 510b9be2..1dd6afae 100644 --- a/doc_source/windows-support.md +++ b/doc_source/windows-support.md @@ -177,7 +177,7 @@ You can use `eksctl`, a Windows client, or a macOS or Linux client to enable leg **To enable legacy Windows support for your cluster with `eksctl`** **Prerequisite** -This procedure requires `eksctl` version `0.76.0` or later\. You can check your version with the following command\. +This procedure requires `eksctl` version `0.77.0` or later\. You can check your version with the following command\. ``` eksctl version