Amazon EKS의 ID 및 접근 관리

Amazon EKS의 ID 및 접근 관리 (Identity and access management)

AWS IAM(Identity and Access Management)은 관리자가 AWS 리소스에 대한 접근을 안전하게 제어하도록 돕는 AWS 서비스예요. IAM 관리자는 누가 Amazon EKS 리소스를 사용하도록 인증(로그인)되고 권한 부여(permissions)되는지 제어해요. IAM은 추가 비용 없이 사용할 수 있는 AWS 서비스예요.

출처: 문서

본문

대상 (Audience)

AWS IAM(Identity and Access Management)을 사용하는 방식은 Amazon EKS에서 하는 작업에 따라 달라져요.

  • 서비스 사용자 (Service user) – Amazon EKS 서비스를 사용해 업무를 수행한다면 관리자가 필요한 자격 증명과 권한을 제공해요. 업무를 위해 더 많은 Amazon EKS 기능을 사용할수록 추가 권한이 필요할 수 있어요. 접근이 어떻게 관리되는지 이해하면 관리자에게 올바른 권한을 요청하는 데 도움이 돼요. Amazon EKS의 기능에 접근할 수 없다면 IAM 문제 해결을 참고하세요.
  • 서비스 관리자 (Service administrator) – 회사에서 Amazon EKS 리소스를 담당한다면 Amazon EKS에 대한 전체 접근 권한을 가질 가능성이 높아요. 서비스 사용자가 어떤 Amazon EKS 기능과 리소스에 접근해야 하는지 결정하는 것이 여러분의 몫이에요. 그런 다음 IAM 관리자에게 서비스 사용자의 권한 변경을 요청해야 해요. 이 페이지의 정보를 검토해 IAM의 기본 개념을 이해하세요. 회사에서 IAM을 Amazon EKS와 함께 사용하는 방법은 Amazon EKS가 IAM과 동작하는 방식을 참고하세요.
  • IAM 관리자 (IAM administrator) – IAM 관리자라면 Amazon EKS 접근을 관리하는 정책을 작성하는 방법에 대한 세부 사항을 알고 싶을 수 있어요. IAM에서 사용할 수 있는 Amazon EKS identity-based policy 예시를 보려면 Amazon EKS identity-based policy examples를 참고하세요.

ID로 인증하기 (Authenticating with identities)

인증(Authentication)은 ID 자격 증명으로 AWS에 로그인하는 방식이에요. AWS 계정 루트 사용자, IAM 사용자로 인증되거나(로그인) IAM 역할을 맡아야 해요.

ID 소스를 통해 제공된 자격 증명으로 연합 ID(federated identity)로 AWS에 로그인할 수 있어요. AWS IAM Identity Center 사용자, 회사의 단일 로그온(single sign-on) 인증, Google 또는 Facebook 자격 증명이 연합 ID의 예시예요. 연합 ID로 로그인하면 관리자가 이전에 IAM 역할로 ID 페더레이션을 설정해 놓은 거예요. 페더레이션으로 AWS에 접근하면 간접적으로 역할을 맡게 돼요.

사용자 유형에 따라 AWS Management Console이나 AWS access portal로 로그인할 수 있어요. AWS 로그인에 대한 자세한 내용은 AWS Sign-In 사용자 가이드의 How to sign in to your AWS account를 참고하세요.

프로그래밍 방식으로 AWS에 접근하면 AWS가 SDK(software development kit)와 CLI(command line interface)를 제공해 자격 증명으로 요청을 암호화 서명할 수 있어요. AWS 도구를 사용하지 않는다면 요청에 직접 서명해야 해요. 직접 서명하는 권장 방식에 대한 자세한 내용은 IAM 사용자 가이드의 Signing AWS API requests를 참고하세요.

어떤 인증 방법을 사용하든 추가 보안 정보를 제공해야 할 수 있어요. 예를 들어 AWS는 계정 보안을 높이기 위해 MFA(multi-factor authentication) 사용을 권장해요. 자세한 내용은 AWS IAM Identity Center 사용자 가이드의 Multi-factor authentication과 IAM 사용자 가이드의 Using multi-factor authentication (MFA) in AWS를 참고하세요.

AWS 계정 루트 사용자

AWS 계정을 만들면 계정의 모든 AWS 서비스와 리소스에 대한 전체 접근 권한을 가진 하나의 로그인 ID로 시작해요. 이 ID를 AWS 계정 루트 사용자라고 하며, 계정을 만들 때 사용한 이메일 주소와 비밀번호로 로그인해 접근해요. 일상적인 작업에는 루트 사용자를 사용하지 않는 것을 강력히 권장해요. 루트 사용자 자격 증명을 잘 보호하고 루트 사용자만 수행할 수 있는 작업에만 사용하세요. 루트 사용자로 로그인해야 하는 전체 작업 목록은 IAM 사용자 가이드의 Tasks that require root user credentials를 참고하세요.

IAM 사용자와 그룹

IAM 사용자는 한 사람 또는 애플리케이션에 대한 특정 권한을 가진 AWS 계정 내의 ID예요. 가능하면 비밀번호와 액세스 키 같은 장기 자격 증명을 가진 IAM 사용자를 만드는 대신 임시 자격 증명에 의존하는 것을 권장해요. 다만 IAM 사용자와 함께 장기 자격 증명이 필요한 특정 사용 사례가 있다면 액세스 키를 정기적으로 교체할 것을 권장해요. 자세한 내용은 IAM 사용자 가이드의 Rotate access keys regularly for use cases that require long-term credentials을 참고하세요.

IAM 그룹은 IAM 사용자 모음을 지정하는 ID예요. 그룹으로 로그인할 수는 없어요. 그룹을 사용해 여러 사용자에게 동시에 권한을 지정할 수 있어요. 그룹은 많은 사용자 집합의 권한을 더 쉽게 관리할 수 있게 해줘요. 예를 들어 IAMAdmins라는 그룹을 만들고 그 그룹에 IAM 리소스를 관리할 권한을 부여할 수 있어요.

사용자는 역할과 달라요. 사용자는 한 사람 또는 애플리케이션과 고유하게 연결되지만, 역할은 필요한 사람이라면 누구나 맡을 수 있도록 의도된 거예요. 사용자는 영구적인 장기 자격 증명을 가지지만 역할은 임시 자격 증명을 제공해요. 자세한 내용은 IAM 사용자 가이드의 When to create an IAM user (instead of a role)을 참고하세요.

IAM 역할

IAM 역할은 특정 권한을 가진 AWS 계정 내의 ID예요. IAM 사용자와 비슷하지만 특정 사람과는 연결되지 않아요. AWS Management Console에서 역할 전환(switching roles)으로 IAM 역할을 임시로 맡을 수 있어요. AWS CLI 또는 AWS API 작업을 호출하거나 사용자 지정 URL로 역할을 맡을 수 있어요. 역할 사용 방법에 대한 자세한 내용은 IAM 사용자 가이드의 Using IAM roles을 참고하세요.

임시 자격 증명이 있는 IAM 역할은 다음 상황에서 유용해요.

  • 연합 사용자 접근 (Federated user access) – 연합 ID에 권한을 할당하려면 역할을 만들고 역할에 대한 권한을 정의하세요. 연합 ID가 인증되면 그 ID가 역할과 연결되어 역할이 정의한 권한을 부여받아요. 페더레이션용 역할에 대한 정보는 IAM 사용자 가이드의 Creating a role for a third-party Identity Provider를 참고하세요. IAM Identity Center를 사용한다면 permission set을 구성하세요. ID가 인증된 후 무엇에 접근할 수 있는지 제어하기 위해 IAM Identity Center는 permission set을 IAM의 역할과 연결해요. permission set에 대한 정보는 AWS IAM Identity Center 사용자 가이드의 Permission sets를 참고하세요.
  • 임시 IAM 사용자 권한 (Temporary IAM user permissions) – IAM 사용자나 역할은 특정 작업을 위해 임시로 다른 권한을 취하도록 IAM 역할을 맡을 수 있어요.
  • 교차 계정 접근 (Cross-account access) – IAM 역할을 사용해 다른 계정의 누군가(신뢰받는 보안 주체)가 계정의 리소스에 접근하도록 허용할 수 있어요. 역할은 교차 계정 접근을 부여하는 기본적인 방법이에요. 다만 일부 AWS 서비스에서는 역할을 프록시로 사용하는 대신 정책을 리소스에 직접 연결할 수 있어요. 교차 계정 접근에서 역할과 리소스 기반 정책의 차이는 IAM 사용자 가이드의 Cross account resource access in IAM을 참고하세요.
  • 교차 서비스 접근 (Cross-service access) – 일부 AWS 서비스는 다른 AWS 서비스의 기능을 사용해요. 예를 들어 서비스에서 호출을 하면 그 서비스가 Amazon EC2에서 애플리케이션을 실행하거나 Amazon S3에 객체를 저장하는 것이 일반적이에요. 서비스는 호출 보안 주체의 권한, 서비스 역할 또는 서비스 연결 역할을 사용해 이 작업을 할 수 있어요.
    • FAS(Forward access sessions) – IAM 사용자나 역할로 AWS에서 작업을 수행하면 보안 주체로 간주돼요. 일부 서비스에서는 다른 서비스에서 다른 작업을 시작하는 작업을 수행할 수 있어요. FAS는 AWS 서비스를 호출하는 보안 주체의 권한과 요청하는 AWS 서비스를 결합해 다운스트림 서비스에 요청을 만들어요. FAS 요청은 서비스가 다른 AWS 서비스나 리소스와의 상호작용이 필요한 요청을 받았을 때만 이루어져요. 이 경우 두 작업 모두 수행할 권한이 있어야 해요. FAS 요청의 정책 세부 사항은 Forward access sessions를 참고하세요.
    • 서비스 역할 (Service role) – 서비스 역할은 서비스가 사용자를 대신해 작업을 수행하기 위해 맡는 IAM 역할이에요. IAM 관리자는 IAM 안에서 서비스 역할을 생성·수정·삭제할 수 있어요. 자세한 내용은 IAM 사용자 가이드의 Creating a role to delegate permissions to an AWS service를 참고하세요.
    • 서비스 연결 역할 (Service-linked role) – 서비스 연결 역할은 AWS 서비스에 연결된 일종의 서비스 역할이에요. 서비스가 역할을 맡아 사용자를 대신해 작업을 수행할 수 있어요. 서비스 연결 역할은 AWS 계정에 나타나며 서비스가 소유해요. IAM 관리자는 서비스 연결 역할의 권한을 볼 수 있지만 편집할 수는 없어요.
  • Amazon EC2에서 실행되는 애플리케이션 (Applications running on Amazon EC2) – IAM 역할을 사용해 EC2 인스턴스에서 실행되며 AWS CLI 또는 AWS API 요청을 하는 애플리케이션의 임시 자격 증명을 관리할 수 있어요. 이는 EC2 인스턴스 안에 액세스 키를 저장하는 것보다 낫습니다. EC2 인스턴스에 AWS 역할을 할당하고 모든 애플리케이션에서 사용할 수 있게 하려면 인스턴스에 연결된 인스턴스 프로필(instance profile)을 만드세요. 인스턴스 프로필은 역할을 포함하며 EC2 인스턴스에서 실행되는 프로그램이 임시 자격 증명을 얻을 수 있게 해줘요. 자세한 내용은 IAM 사용자 가이드의 Using an IAM role to grant permissions to applications running on Amazon EC2 instances를 참고하세요.

IAM 역할을 사용할지 IAM 사용자를 사용할지 알아보려면 IAM 사용자 가이드의 When to create an IAM role (instead of a user)을 참고하세요.

정책으로 접근 관리하기 (Managing access using policies)

AWS에서 접근을 제어하려면 정책을 만들고 AWS ID 또는 리소스에 연결하세요. 정책은 ID나 리소스와 연결될 때 그들의 권한을 정의하는 AWS 객체예요. AWS는 보안 주체(사용자, 루트 사용자 또는 역할 세션)가 요청을 할 때 이러한 정책을 평가해요. 정책의 권한이 요청 허용 또는 거부 여부를 결정해요. 대부분의 정책은 AWS에 JSON 문서로 저장돼요. JSON 정책 문서의 구조와 내용에 대한 자세한 내용은 IAM 사용자 가이드의 Overview of JSON policies를 참고하세요.

관리자는 AWS JSON 정책으로 누가 무엇에 접근할 수 있는지 지정할 수 있어요. 즉 어떤 보안 주체가 어떤 리소스에서 어떤 작업을 수행할 수 있고 어떤 조건에서 가능한지요.

기본적으로 사용자와 역할은 권한이 없어요. 사용자에게 필요한 리소스에서 작업을 수행할 권한을 부여하려면 IAM 관리자가 IAM 정책을 만든 다음 그 정책을 역할에 추가하고 사용자가 역할을 맡을 수 있게 해요.

IAM 정책은 작업 수행에 사용하는 방법과 무관하게 작업에 대한 권한을 정의해요. 예를 들어 iam:GetRole 작업을 허용하는 정책이 있다고 가정해 보세요. 그 정책이 있는 사용자는 AWS Management Console, AWS CLI 또는 AWS API에서 역할 정보를 가져올 수 있어요.

ID 기반 정책 (Identity-based policies)

ID 기반 정책은 IAM 사용자, 사용자 그룹 또는 역할 같은 ID에 연결할 수 있는 JSON 권한 정책 문서예요. 이러한 정책은 사용자와 역할이 어떤 리소스에서 어떤 작업을 수행할 수 있고 어떤 조건에서 가능한지 제어해요. ID 기반 정책을 만드는 방법은 IAM 사용자 가이드의 Creating IAM policies를 참고하세요.

ID 기반 정책은 인라인 정책(inline policies) 또는 관리형 정책(managed policies)으로 더 세분화할 수 있어요. 인라인 정책은 단일 사용자, 그룹 또는 역할에 직접 포함돼요. 관리형 정책은 AWS 계정의 여러 사용자, 그룹, 역할에 연결할 수 있는 독립 정책이에요. 관리형 정책에는 AWS 관리형 정책과 고객 관리형 정책이 있어요. 관리형 정책과 인라인 정책 중 선택하는 방법은 IAM 사용자 가이드의 Choosing between managed policies and inline policies를 참고하세요.

리소스 기반 정책 (Resource-based policies)

리소스 기반 정책은 리소스에 연결하는 JSON 정책 문서예요. 리소스 기반 정책의 예시로는 IAM 역할 신뢰 정책과 Amazon S3 버킷 정책이 있어요. 리소스 기반 정책을 지원하는 서비스에서는 서비스 관리자가 정책을 사용해 특정 리소스에 대한 접근을 제어할 수 있어요. 정책이 연결된 리소스에 대해, 정책은 지정된 보안 주체가 그 리소스에서 어떤 작업을 수행할 수 있고 어떤 조건에서 가능한지 정의해요. 리소스 기반 정책에서는 보안 주체를 반드시 지정해야 해요. 보안 주체에는 계정, 사용자, 역할, 연합 사용자 또는 AWS 서비스가 포함될 수 있어요.

리소스 기반 정책은 해당 서비스에 있는 인라인 정책이에요. 리소스 기반 정책에서 IAM의 AWS 관리형 정책을 사용할 수는 없어요.

ACL(접근 제어 목록)

ACL(Access control lists)은 어떤 보안 주체(계정 구성원, 사용자 또는 역할)가 리소스에 접근할 권한이 있는지 제어해요. ACL은 리소스 기반 정책과 비슷하지만 JSON 정책 문서 형식을 사용하지 않아요.

Amazon S3, AWS WAF, Amazon VPC는 ACL을 지원하는 서비스의 예시예요. ACL에 대해 더 알아보려면 Amazon Simple Storage Service 개발자 가이드의 Access control list (ACL) overview를 참고하세요.

기타 정책 유형

AWS는 추가적이고 덜 일반적인 정책 유형을 지원해요. 이러한 정책 유형은 더 일반적인 정책 유형이 부여하는 최대 권한을 설정할 수 있어요.

  • 권한 경계 (Permissions boundaries) – 권한 경계는 ID 기반 정책이 IAM 엔터티(IAM 사용자 또는 역할)에 부여할 수 있는 최대 권한을 설정하는 고급 기능이에요. 엔터티에 대한 권한 경계를 설정할 수 있어요. 결과적으로 얻게 되는 권한은 엔터티의 ID 기반 정책과 권한 경계의 교집합이에요. Principal 필드에 사용자나 역할을 지정하는 리소스 기반 정책은 권한 경계의 제한을 받지 않아요. 이러한 정책 중 하나의 명시적 거부는 허용보다 우선해요. 권한 경계에 대한 자세한 내용은 IAM 사용자 가이드의 Permissions boundaries for IAM entities를 참고하세요.
  • SCP(서비스 제어 정책) – SCP는 AWS Organizations에서 조직 또는 OU(organizational unit)의 최대 권한을 지정하는 JSON 정책이에요. AWS Organizations는 비즈니스가 소유한 여러 AWS 계정을 그룹화하고 중앙에서 관리하는 서비스예요. 조직에서 모든 기능을 활성화하면 모든 계정에 SCP를 적용할 수 있어요. SCP는 각 AWS 계정 루트 사용자를 포함해 멤버 계정의 엔터티 권한을 제한해요. Organizations와 SCP에 대한 자세한 내용은 AWS Organizations 사용자 가이드의 Service control policies를 참고하세요.
  • 세션 정책 (Session policies) – 세션 정책은 역할이나 연합 사용자에 대한 임시 세션을 프로그래밍 방식으로 만들 때 파라미터로 전달하는 고급 정책이에요. 결과 세션의 권한은 사용자나 역할의 ID 기반 정책과 세션 정책의 교집합이에요. 권한은 리소스 기반 정책에서 올 수도 있어요. 이러한 정책 중 하나의 명시적 거부는 허용보다 우선해요. 자세한 내용은 IAM 사용자 가이드의 Session policies를 참고하세요.

여러 정책 유형

요청에 여러 유형의 정책이 적용되면 결과적으로 얻게 되는 권한을 이해하기가 더 복잡해져요. 여러 정책 유형이 관련될 때 AWS가 요청을 허용할지 결정하는 방법은 IAM 사용자 가이드의 Policy evaluation logic을 참고하세요.

더 알아보기 (Learn more)