AWS eks documentation change
Summary
Fixed typos in documentation about IAM roles for service accounts (IRSA) and EKS Pod Identity - changed 'build' to 'built' and corrected spelling of 'unnecessary'
Security assessment
These are minor typographical corrections with no substantive changes to security content. The changes fix grammar and spelling errors but do not alter security guidance, introduce new security features, or address specific vulnerabilities.
Diff
diff --git a/eks/latest/userguide/service-accounts.md b/eks/latest/userguide/service-accounts.md index c8d3b91d5..2d2b89b6f 100644 --- a//eks/latest/userguide/service-accounts.md +++ b//eks/latest/userguide/service-accounts.md @@ -84 +84 @@ Amazon EKS provides two ways to grant AWS Identity and Access Management permiss -_IAM roles for service accounts (IRSA)_ configures Kubernetes applications running on AWS with fine-grained IAM permissions to access various other AWS resources such as Amazon S3 buckets, Amazon DynamoDB tables, and more. You can run multiple applications together in the same Amazon EKS cluster, and ensure each application has only the minimum set of permissions that it needs. IRSA was build to support various Kubernetes deployment options supported by AWS such as Amazon EKS, Amazon EKS Anywhere, Red Hat OpenShift Service on AWS, and self managed Kubernetes clusters on Amazon EC2 instances. Thus, IRSA was build using foundational AWS service like IAM, and did not take any direct dependency on the Amazon EKS service and the EKS API. For more information, see [IAM roles for service accounts](./iam-roles-for-service-accounts.html). +_IAM roles for service accounts (IRSA)_ configures Kubernetes applications running on AWS with fine-grained IAM permissions to access various other AWS resources such as Amazon S3 buckets, Amazon DynamoDB tables, and more. You can run multiple applications together in the same Amazon EKS cluster, and ensure each application has only the minimum set of permissions that it needs. IRSA was built to support various Kubernetes deployment options supported by AWS such as Amazon EKS, Amazon EKS Anywhere, Red Hat OpenShift Service on AWS, and self managed Kubernetes clusters on Amazon EC2 instances. Thus, IRSA was build using foundational AWS service like IAM, and did not take any direct dependency on the Amazon EKS service and the EKS API. For more information, see [IAM roles for service accounts](./iam-roles-for-service-accounts.html). @@ -104 +104 @@ Role scalability | EKS Pod Identity doesn’t require users to define trust rel -STS API Quota Usage | EKS Pod Identity simplifies delivery of AWS credentials to your pods, and does not require your code make calls with the AWS Security Token Service (STS) directly. The EKS service handles role assumption, and delivers credentials to applications written using the AWS SDK in your pods without your pods communicating with AWS STS or using STS API Quota. | In IRSA, applications written using the AWS SDK in your pods use tokens to call the `AssumeRoleWithWebIdentity` API on the AWS Security Token Service (STS). Depending on the logic of your code on the AWS SDK, it is possible for your code to make unneccesarry calls to AWS STS and receive throttling errors. +STS API Quota Usage | EKS Pod Identity simplifies delivery of AWS credentials to your pods, and does not require your code make calls with the AWS Security Token Service (STS) directly. The EKS service handles role assumption, and delivers credentials to applications written using the AWS SDK in your pods without your pods communicating with AWS STS or using STS API Quota. | In IRSA, applications written using the AWS SDK in your pods use tokens to call the `AssumeRoleWithWebIdentity` API on the AWS Security Token Service (STS). Depending on the logic of your code on the AWS SDK, it is possible for your code to make unnecessary calls to AWS STS and receive throttling errors.