액세스 항목 생성 - Amazon EKS

이 페이지 개선에 도움 주기

이 사용자 설명서에 기여하고 싶으신가요? 이 페이지 하단으로 스크롤하여 GitHub에서 이 페이지 편집을 선택하세요. 여러분의 기여는 모두를 위한 더 나은 사용자 설명서를 만드는 데 도움이 됩니다.

액세스 항목 생성

고려 사항

액세스 항목을 생성하기 전에 다음을 고려합니다.

  • 올바르게 설정된 인증 모드입니다. 액세스 항목을 사용하도록 인증 모드 변경 섹션을 참조하세요.

  • 액세스 항목에는 기존 IAM 보안 주체 하나의 Amazon 리소스 이름(ARN)만 포함됩니다. IAM 보안 주체는 둘 이상의 액세스 항목에 포함될 수 없습니다. 지정하는 ARN에 대한 추가 고려 사항:

    • IAM 모범 사례에서는 장기 보안 인증 정보를 보유한 IAM 사용자 대신, 단기 보안 인증 정보를 보유한 IAM 역할을 사용하여 클러스터에 액세스하도록 권장합니다. 자세한 내용은 IAM 사용 설명서에서 임시 보안 인증을 사용하여 AWS에 액세스하려면 인간 사용자가 ID 공급자와의 페더레이션을 사용하도록 요구합니다.를 참조하세요.

    • IAM 역할에 대한 ARN인 경우 경로를 포함할 수 있습니다. aws-auth ConfigMap 항목의 ARN은 경로를 포함할 수 없습니다. 예를 들어 ARN은 arn:aws:iam::111122223333:role/development/apps/my-role 또는 arn:aws:iam::111122223333:role/my-role일 수 있습니다.

    • 액세스 항목 유형이 STANDARD 이외의 유형인 경우(유형에 대한 다음 고려 사항 참조) ARN은 클러스터가 속한 같은 AWS 계정에 있어야 합니다. 유형이 STANDARD인 경우 ARN은 클러스터가 있는 계정과 같거나 다른 AWS 계정에 있을 수 있습니다.

    • 액세스 항목이 생성된 후에는 IAM 보안 주체를 변경할 수 없습니다.

    • 이 ARN으로 IAM 보안 주체를 삭제해도 액세스 항목은 자동으로 삭제되지 않습니다. 삭제하는 IAM 보안 주체에 대한 ARN을 사용하여 액세스 항목을 삭제하는 것이 좋습니다. 액세스 항목을 삭제하지 않고 IAM 보안 주체를 다시 생성하면 ARN이 같아도 액세스 항목이 작동하지 않습니다. 다시 생성된 IAM 보안 주체에서 ARN이 동일하더라도 roleID 또는 userID(aws sts get-caller-identity AWS CLI 명령으로 확인할 수 있음)는 다시 생성된 IAM 보안 주체의 해당 항목과 다릅니다(원래 IAM 보안 주체의 항목임). 액세스 항목의 IAM 보안 주체 roleID 또는 userID가 표시되지 않더라도 Amazon EKS는 액세스 항목과 함께 이를 저장합니다.

  • 각 액세스 항목에는 유형이 있습니다. EC2 Linux(Linux 또는 Bottlerocket 자체 관리형 노드에 사용되는 IAM 역할의 경우), EC2 Windows(Windows 자체 관리형 노드에 사용되는 IAM 역할의 경우), FARGATE_LINUX(AWS Fargate에서 사용되는 IAM 역할의 경우) 또는 STANDARD를 유형으로 지정할 수 있습니다. 유형을 지정하지 않으면 Amazon EKS에서 자동으로 유형을 STANDARD로 설정합니다. Amazon EKS는 클러스터의 플랫폼 버전에 상관없이 aws-auth ConfigMap에 해당 역할의 항목을 추가하기 때문에 관리형 노드 그룹 또는 Fargate 프로파일에 사용되는 IAM 역할에 대한 액세스 항목을 생성하지 않아도 됩니다.

    액세스 항목을 생성한 후에는 유형을 변경할 수 없습니다.

  • 액세스 항목 유형이 STANDARD인 경우 액세스 항목의 사용자 이름을 지정할 수 있습니다. 사용자 이름 값을 지정하지 않는 경우 Amazon EKS는 지정한 IAM 보안 주체(IAM 역할 또는 IAM 사용자) 및 액세스 항목의 유형에 따라 다음 값 중 하나를 자동으로 설정합니다. 고유한 사용자 이름을 지정해야 하는 특별한 이유가 없는 한, 사용자 이름을 지정하지 말고 Amazon EKS에서 자동으로 생성하게 두는 것이 좋습니다. 고유한 사용자 이름을 지정하는 경우:

    • system:, eks:, aws:, amazon: 또는 iam:으로 시작할 수 없습니다.

    • IAM 역할에 대한 사용자 이름인 경우 사용자 이름 끝에 {{SessionName}}을 추가하는 것이 좋습니다. 사용자 이름에 {{SessionName}}을 추가하는 경우 사용자 이름에서 {{SessionName}} 앞에 콜론을 포함해야 합니다. 이 역할을 수임하면 역할을 수임할 때 지정한 세션 이름이 클러스터에 자동으로 전달되고 CloudTrail 로그에 표시됩니다. 예를 들어 john{{SessionName}}의 사용자 이름을 포함할 수 없습니다. 사용자 이름은 :john{{SessionName}} 또는 jo:hn{{SessionName}}이어야 합니다. 콜론은 {{SessionName}} 앞에 와야 합니다. 다음 테이블에서 Amazon EKS가 생성한 사용자 이름에는 ARN이 포함됩니다. ARN에는 콜론이 포함되므로 이 요구 사항을 충족합니다. 사용자 이름에 {{SessionName}}을 포함하지 않는 경우 콜론은 필요하지 않습니다.

    IAM 보안 주체 유형 유형 Amazon EKS가 자동으로 설정하는 사용자 이름 값
    User STANDARD

    사용자의 ARN. 예시: arn:aws:iam::111122223333:user/my-user
    역할 STANDARD

    역할을 수임한 경우 STS ARN. Amazon EKS가 역할에 {{SessionName}}을 추가합니다.

    예시: arn:aws:sts::111122223333:assumed-role/my-role/{{SessionName}}

    지정한 역할의 ARN에 경로가 포함된 경우 Amazon EKS는 생성된 사용자 이름에서 해당 경로를 제거합니다.
    역할 EC2 Linux 또는 EC2 Windows

    system:node:{{EC2PrivateDNSName}}
    역할 FARGATE_LINUX

    system:node:{{SessionName}}

    액세스 항목을 생성한 후 사용자 이름을 변경할 수 있습니다.

  • 액세스 항목 유형이 STANDARD이고 Kubernetes RBAC 권한 부여를 사용하려는 경우 액세스 항목에 하나 이상의 그룹 이름을 추가할 수 있습니다. 액세스 항목을 생성한 후 그룹 이름을 추가 및 제거할 수 있습니다. IAM 보안 주체가 클러스터의 Kubernetes 객체에 액세스할 수 있으려면 Kubernetes 역할 기반 권한 부여(RBAC) 객체를 생성하고 관리해야 합니다. 클러스터에서 kind: Group에 대해 그룹 이름을 subject로 지정하는 Kubernetes RoleBinding 또는 ClusterRoleBinding 객체를 생성합니다. Kubernetes에서는 Kubernetes Role 또는 ClusterRole 객체에 지정한 클러스터 객체(바인딩의 roleRef에서도 지정함)에 대한 액세스 권한을 IAM 보안 주체에 부여합니다. 그룹 이름을 지정하는 경우 Kubernetes 역할 기반 인증(RBAC) 객체에 익숙해지는 것이 좋습니다. 자세한 내용은 Kubernetes 설명서의 RBAC 승인 사용을 참조하세요.

    중요

    Amazon EKS는 클러스터에 있는 Kubernetes RBAC 객체에 지정한 그룹 이름이 포함되었는지 확인하지 않습니다.

    Kubernetes에서 클러스터의 Kubernetes 객체에 대한 액세스 권한을 IAM 보안 주체에 부여하는 대신 또는 이 방법 외에도 Amazon EKS 액세스 정책을 액세스 항목에 연결할 수 있습니다. Amazon EKS는 IAM 보안 주체에 액세스 정책의 권한과 함께 클러스터의 Kubernetes 객체에 액세스할 수 있는 권한을 부여합니다. 지정한 Kubernetes 네임스페이스로 액세스 정책의 권한 범위를 지정할 수 있습니다. 액세스 정책을 사용할 경우 Kubernetes RBAC 객체를 관리할 필요가 없습니다. 자세한 내용은 액세스 정책을 액세스 항목과 연결 단원을 참조하십시오.

  • 유형이 EC2 Linux 또는 EC2 Windows인 액세스 항목을 생성하는 경우 액세스 항목을 생성하는 IAM 보안 주체에 iam:PassRole 권한이 있어야 합니다. 자세한 내용은 IAM 사용 설명서에서 사용자에게 AWS 서비스에 역할을 전달할 권한 부여를 참조하세요.

  • 표준 IAM 동작과 마찬가지로, 액세스 항목 생성 및 업데이트는 실질적으로 일관되며 초기 API 직접 호출이 성공적으로 반환된 후 효력이 발생하는 데 몇 초가 걸릴 수 있습니다. 이러한 잠재적 지연을 고려하도록 애플리케이션을 설계해야 합니다. 액세스 항목 생성 또는 업데이트는 애플리케이션의 중요한 고가용성 코드 경로에 포함하지 않는 것이 좋습니다. 대신 자주 실행하지 않는 별도의 초기화 루틴이나 설정 루틴에서 을 변경하십시오. 또한 프로덕션 워크플로우에서 변경 사항을 적용하기 전에 변경 사항이 전파되었는지 확인하세요.

  • 액세스 항목은 서비스 연결 역할을 지원하지 않습니다. 보안 주체 ARN이 서비스 연결 역할인 경우 액세스 항목을 생성할 수 없습니다. arn:aws:iam::*:role/aws-service-role/* 형식의 ARN으로 서비스 연결 역할을 식별할 수 있습니다.

AWS Management Console 또는 AWS CLI를 사용하여 액세스 항목을 생성할 수 있습니다.

AWS Management Console
액세스 항목을 생성하는 방법

  1. https://console.aws.amazon.com/eks/home#/clusters에서 Amazon EKS 콘솔을 엽니다.

  2. 관리형 노드 그룹을 생성하려는 클러스터의 이름을 선택합니다.

  3. 액세스 탭을 선택합니다.

  4. 액세스 항목 생성을 선택합니다.

  5. IAM 보안 주체의 경우 기존 IAM 역할 또는 사용자를 선택합니다. IAM 모범 사례에서는 장기 보안 인증 정보를 보유한 IAM 사용자 대신, 단기 보안 인증 정보를 보유한 IAM 역할을 사용하여 클러스터에 액세스하도록 권장합니다. 자세한 내용은 IAM 사용 설명서에서 임시 보안 인증을 사용하여 AWS에 액세스하려면 인간 사용자가 ID 공급자와의 페더레이션을 사용하도록 요구합니다.를 참조하세요.

  6. 자체 관리형 Amazon EC2 노드에 사용되는 노드 역할에 대한 액세스 항목인 경우 유형에서 EC2 Linux 또는 EC2 Windows를 선택합니다. 그렇지 않으면 기본값(표준)을 그대로 수락합니다.

  7. 선택한 유형이 표준이고 사용자 이름을 지정하려면 사용자 이름을 입력합니다.

  8. 선택한 유형이 표준이고 IAM 보안 주체에 대해 Kubernetes RBAC 권한 부여를 사용하려는 경우 그룹에 대한 하나 이상의 이름을 지정합니다. 그룹 이름을 지정하지 않고 Amazon EKS 권한 부여를 사용하려는 경우 이후 단계에서 또는 액세스 항목을 생성한 후에 액세스 정책을 연결할 수 있습니다.

  9. (선택 사항) 태그에서 액세스 항목에 레이블을 할당합니다. 예를 들어 태그가 동일한 모든 리소스를 더 쉽게 찾을 수 있습니다.

  10. Next(다음)를 선택합니다.

  11. 액세스 정책 추가 페이지에서 선택한 유형이 표준이고 Amazon EKS가 IAM 보안 주체에 클러스터의 Kubernetes 객체에 대한 권한을 부여하게 하려면 다음 단계를 완료합니다. 그렇지 않은 경우 [Next]를 선택합니다.

    1. 정책 이름에서 액세스 정책을 선택합니다. 액세스 정책의 권한은 볼 수 없지만 Kubernetes 사용자 대면 ClusterRole 객체에서 이와 유사한 권한을 포함합니다. 자세한 내용은 Kubernetes 설명서에서 User-facing roles를 참조하세요.

    2. 다음 옵션 중 하나를 선택하세요:

      • 클러스터 - Amazon EKS에서 IAM 보안 주체가 클러스터의 모든 Kubernetes 객체에 대한 액세스 정책의 권한을 갖도록 권한을 부여하려면 이 옵션을 선택합니다.

      • Kubernetes 네임스페이스 - Amazon EKS에서 IAM 보안 주체가 클러스터 내 특정 Kubernetes 네임스페이스의 모든 Kubernetes 객체에 대한 액세스 정책의 권한을 갖도록 권한을 부여하려면 이 옵션을 선택합니다. 네임스페이스의 경우 클러스터의 Kubernetes 네임스페이스 이름을 입력합니다. 네임스페이스를 더 추가하려면 새 네임스페이스 추가를 선택하고 네임스페이스 이름을 입력합니다.

    3. 정책을 더 추가하려면 정책 추가를 선택합니다. 각 정책의 범위를 다르게 지정할 수 있지만 각 정책은 한 번만 추가할 수 있습니다.

    4. Next(다음)를 선택합니다.

  12. 액세스 항목의 구성을 검토합니다. 문제가 있는 것 같으면 이전을 선택하여 이전 단계로 돌아가서 오류를 수정합니다. 구성이 올바르면 생성을 선택합니다.

AWS CLI
전제 조건

AWS CLI를 설치하려면 AWS Command Line Interface 사용 설명서의 AWS CLI 설치, 업데이트 및 제거를 참조하세요.

액세스 항목을 생성하는 방법

다음 예제를 사용하여 액세스 항목을 생성할 수 있습니다.

  • 자체 관리형 Amazon EC2 Linux 노드 그룹에 대한 액세스 항목을 생성합니다. my-cluster를 클러스터 이름으로, 111122223333을 AWS 계정 ID로, EKS-my-cluster-self-managed-ng-1을 노드 IAM 역할로 바꿉니다. 노드 그룹이 Windows 노드 그룹인 경우 EC2_Linux를 EC2_Windows로 바꿉니다.

    aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/EKS-my-cluster-self-managed-ng-1 --type EC2_Linux

    STANDARD 이외의 유형을 지정할 때는 이 --kubernetes-groups 옵션을 사용할 수 없습니다. 유형이 STANDARD 이외의 값이므로 액세스 정책을 이 액세스 항목에 연결할 수 없습니다.

  • Kubernetes에서 클러스터에 대한 액세스를 부여하려는 Amazon EC2 자체 관리형 노드 그룹에 사용되지 않는 IAM 역할을 허용하는 액세스 항목을 생성합니다. my-cluster를 클러스터 이름으로, 111122223333을 AWS 계정 ID로, my-role을 IAM 역할 이름으로 바꿉니다. Viewers를 클러스터의 Kubernetes RoleBinding 또는 ClusterRoleBinding 객체에 지정한 그룹 이름으로 바꿉니다.

    aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role --type STANDARD --user Viewers --kubernetes-groups Viewers

  • 클러스터에서 IAM 사용자를 인증할 수 있는 액세스 항목을 생성합니다. IAM 모범 사례에서는 장기 보안 인증 정보를 보유한 IAM 사용자 대신, 단기 보안 인증 정보를 보유한 IAM 역할을 사용하여 클러스터에 액세스하도록 권장하지만, 이 예제는 가능한 상황을 보여줍니다. 자세한 내용은 IAM 사용 설명서에서 임시 보안 인증을 사용하여 AWS에 액세스하려면 인간 사용자가 ID 공급자와의 페더레이션을 사용하도록 요구합니다.를 참조하세요.

    aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:user/my-user --type STANDARD --username my-user

    이 사용자에게 Kubernetes API 검색 역할의 권한보다 더 많은 액세스 권한을 부여하려는 경우 --kubernetes-groups 옵션이 사용되지 않으므로 액세스 정책을 액세스 항목에 연결해야 합니다. 자세한 내용은 Kubernetes 설명서에서 액세스 정책을 액세스 항목과 연결 및 API discovery roles를 참조하세요.