Category: AWS IAM


AWS CodeCommit을 위한 IAM 기반 아이디 생성 및 인증하기

HTTPS를 통해 AWS CodeCommit 저장소(repository)에 인증하는 간단한 방법을 소개합니다.

Git 자격 증명(Git Credentials)을 사용하면, 명령 줄이나 Git CLI, 혹은 HTTPS 인증을 지원하는 어떤 Git 도구에서든 AWS CodeCommit 저장소에 액세스하는데 사용 할 수 있는 정적 사용자 이름과 암호를 IAM (Identity and Access Management) 콘솔에서 생성 할 수 있습니다.이는 정적 자격 증명이기 때문에, 로컬 운영 체제에 포함된 암호 관리 도구를 사용하여 캐시하거나 자격 증명 관리 유틸리티에 저장할 수 있습니다. 이를 통해 수분 내에 AWS CodeCommit을 시작 할 수 있습니다.

HTTPS를 통해 AWS CodeCommit 저장소에 연결하기 위해 AWS CLI를 다운로드하거나 Git 클라이언트를 구성 할 필요가 없습니다. 또한 인기있는 Git GUI 클라이언트 (예 : TowerUI)와 IDE(예 : Eclipse, IntelliJ 및 Visual Studio)등 사용자 이름과 비밀번호를 이용한 인증을 지원하는 타사 도구에서 AWS CodeCommit 저장소를 손쉽게 연결할 수 있습니다.그러면 이 기능을 왜 추가했을까요? 이전까지 HTTPS 연결을 통해 AWS CodeCommit을 이용하려는 사용자는 인증을 위해 AWS credential helper를 구성해야했습니다.

일부 고객 분들은 이러한 credential helper가 가끔씩 Keychain Access와 Windows Vault 같은 암호 관리 도구를 방해하여 인증 실패를 발생시킨다고 말했습니다. 또한 많은 Git GUI 도구와 IDE는 원격 Git 저장소에 연결하기 위해 정적 사용자 이름과 암호가 필요하며 credential helper를 이용한 연결을 지원하지 않습니다.이번 블로그 게시물에서는 AWS CodeCommit 저장소 생성, Git 자격 증명 생성, AWS CodeCommit 저장소에 대한 CLI Access 설정 과정을 설명합니다.

Git Credentials 실습
Dave가 AWS CodeCommit에서 저장소를 만들고 그의 컴퓨터에서 로컬 액세스를 설정하려는 상황을 가정 해봅시다.

선행 조건: Dave가 이전에 로컬 컴퓨터에 AWS CodeCommit에 대한 credential helper를 구성한 경우, .gitconfig 파일을 편집하여 해당 정보를 제거해야 합니다. 또한 로컬 컴퓨터가 MacOS인 경우 Keychain Access에서 캐시된 자격 증명을 지워야 할 수 있습니다.

Git 자격 증명을 이용하면, Dave는 이제 4 단계의 간단한 작업으로 저장소를 만들고 AWS CodeCommit을 사용 할 수 있습니다.

1 단계: IAM 사용자에게 필수 권한이 ​​있는지 확인합니다.
Dave가 Git 자격 증명을 이용한 AWS CodeCommit 액세스 권한을 설정하려면 그의 IAM 사용자이 아래 관리 정책(managed policies)에 연결되어 있어야 합니다. (또는 이와 동등한 권한)

  • AWSCodeCommitPowerUser (or an appropriate CodeCommit managed policy)
  • IAMSelfManageServiceSpecificCredentials
  • IAMReadOnlyAccess

2 단계 : AWS CodeCommit 저장소를 생성합니다.
다음으로, AWS CodeCommit 콘솔에 로그인하고 저장소가 없는 경우 새로 저장소를 만듭니다. 액세스 권한이 있다면 AWS 계정 내 어떤 저장소를 선택하여도 괜찮습니다. Git 자격 증명을 만드는 방법은 도움말 패널에 나와 있습니다. (지시 사항이 표시되지 않으면 연결 단추를 선택하십시오.) IAM 사용자 링크를 클릭하면 IAM 콘솔이 열리며 자격 증명을 생성 할 수 있습니다. (역자주: 현재 AWS CodeCommit은 한국어 콘솔을 제공하고 있습니다.)

3 단계 : IAM 콘솔에서 HTTPS Git 자격 증명 만들기
IAM 사용자 페이지에서, Security Credentials 탭을 선택한 후 HTTPS Git credentials for AWS CodeCommit 영역의 Generate 버튼을 클릭합니다. 사용자 이름과 암호가 생성되고 표시됩니다. 자격 증명을 파일로 다운로드 할 수 있습니다.

GitCred_Blog2

Note: 이 단계에서만 암호를 확인하거나 다운로드할 수 있습니다.

4 단계 : 로컬 시스템 저장소에 복제합니다.
AWS CodeCommit 콘솔 페이지에서 Clone URL을 선택한 다음, 저장소 복제를 위한 HTTPS 링크를 복사합니다. 명령 행이나 터미널에서 방금 복사한 링크를 사용하여 저장소를 복제합니다. 예를 들어 다음과 같이 HTTP 링크를 복사하고,

그런 다음, 명령 줄이나 터미널에 아래와 같이 입력합니다.

$ git clone https://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/TestRepo_Dave

사용자 이름과 암호를 묻는 메시지가 나타나면 3 단계에서 생성 한 Git 자격 증명 (사용자 이름과 암호)을 제공합니다.

이제 코드를 새 저장소로 푸시할 준비가 되었습니다.

Git 자격 증명은 요구 사항에 따라 활성화하거나 비활성화 할 수 있습니다. 또한 필요한 경우, 암호를 재설정 할 수도 있습니다.

다음 단계

  1. 필요에 따라 Git 자격 증명 캐싱 명령(링크를 참조)을 사용하여 자격 증명을 캐시 할 수 있습니다 .
  2. 공동 작업자를 AWS CodeCommit 저장소에서 작업 할 수 있도록 초대하고 싶습니까? AWS 계정에 새 IAM 사용자를 만들고, 해당 사용자에 대한 Git 자격 증명을 만든 후 저장소 URL과 Git 자격 증명을 공동 작업하려는 사람과 안전하게 공유하기 만하면 됩니다.
  3. Git 자격 증명 (저장된 사용자 이름 및 비밀번호)을 통한 원격 Git 리포지토리 연결을 지원하는 타사 클라이언트(third-party client)에 연결합니다. 사실상 모든 도구와 IDE를 정적 자격 증명을 사용하여 연결할 수 있습니다. 우리는 다음을 테스트했습니다 :
    • Visual Studio (기본 Git plugin 사용)
    • Eclipse IDE (기본 Git plugin 사용)
    • Git Tower UI

자세한 내용은 AWS CodeCommit 설명서를 참조하십시오.

AWS CodeCommit에 연결하는 새로운 방법을 제공하게 된 것을 기쁘게 생각합니다. 더 많은 Tool과 IDE에서 AWS CodeCommit 저장소를 사용하실 수 있기를 바랍니다.

이 글은 AWS DevOps 블로그의 Introducing Git Credentials: A Simple Way to Connect to AWS CodeCommit Repositories Using a Static User Name and Password의 한국어 번역으로 강정희 솔루션즈 아키텍트께서 번역해 주셨습니다.

IAM 정책 요약 기능 출시! JSON 문법의 복잡한 정책을 손쉽게 이해하기

오늘 부터 IAM 콘솔에 정책 요약(Policy Summary)기능을 추가하여, AWS IAM 정책 사용 권한을 보다 쉽게 ​​이해할 수 있습니다. JSON 문서를 보는 대신 AWS 서비스, 작업, 리소스 및 각 정책 조건을 요약 한 테이블을 보실 수 있습니다. 본 정책 요약 기능은 정책 정보 페이지 또는 개별 IAM 사용자 페이지 Permissions 탭에서 찾을 수 있습니다.

이 글에서는 정책 요약 기능과 세부 사항을 소개합니다.

정책 요약 기능 사용하기
다음 스크린 샷은 정책 요약 예제를 보여줍니다. 이 표에는 각 서비스가 부여한 접근 수준, 자원 및 조건을 한 눈에 볼 수 있습니다.

정책 요약의 각 열은 다음과 같이 정의됩니다.

  • Service – 정책에 정의된 Amazon 서비스. 각 서비스 이름을 클릭하면 해당 서비스에 부여 된 특정 작업을 볼 수 있습니다.
  • Access level – 정책의 각 서비스에 대해 정의 된 작업 (자세한 내용은 아래에 나와 있습니다).
  • Resource – 정책의 각 서비스에 대해 정의 된 리소스입니다. 이 열은 다음 값 중 하나를 표시합니다.
    • All resources – 서비스의 모든 리소스에 접근 허용 혹은  거부됩니다.
    • Multiple – 일부 자원에 대해서만 서비스에서 부여되거나 거부됩니다.
    • Amazon Resource Name (ARN) – 본 정책은 서비스에서 하나의 리소스를 정의합니다. 하나의 리소스에 대해 실제 ARN이 표시됩니다.
  • Request condition – 각 서비스에 대해 정의 된 조건입니다. 조건은 서비스에 특정한 전역 조건 또는 일부 조건 일 수 있습니다. 이 열은 다음 값 중 하나를 표시합니다.
    • None – 서비스에 대해 조건이 정의되지 않았습니다.
    • Multiple – 서비스에 대해 여러 조건이 정의됩니다.
    • Condition – 서비스에 대해 하나의 조건이 정의되고, 서비스에 대한 정책에 정의 된 모든 작업에 적용됩니다. 각 표에 정책에 정의 된 조건이 표시됩니다. 예를 들어 앞의 스크린 샷은 Amazon Elastic Beanstalk의 조건을 보여줍니다.

JSON에서 정책을 읽고 관리하려는 경우, 정책 요약 위의 View and edit JSON을 선택하십시오.  정책 요약 예제를 살펴보기 전에 새로운 개념인 접근 수준을 자세히 설명하겠습니다.

접근 수준 알아보기
IAM 정책에 정의한 권한을 이해하는 데 도움이 되도록 각 AWS 서비스의 작업은 목록 보기, 읽기, 쓰기 및 전체 권한 관리 등 네 가지 접근 수준으로 분류됩니다. 아래 표는 Amazon S3 접근 수준을 정의하고 이를 사용하는 예제를 제공합니다. Full 및 Limited는 각 서비스에 대한 접근 수준을 추가로 제한합니다. Full은 수준 내의 모든 동작을 나타내며, Limited는 접근 수준에서 하나 이상의 동작을 나타내지만, 모든 동작을 의미하지는 않습니다.  (참고: 자세한 사항은 AWS IAM Policy Actions Grouped by Access Level  문서를 참고하시기 바랍니다.)

접근 수준
소개 예제
List 리소스 목록을 볼 수 있는 작업 s3:ListBucket, s3:ListAllMyBuckets
Read 리소스의 내용을 읽을 수 있는 작업 s3:GetObject, s3:GetBucketTagging
Write 자원을 생성, 삭제 또는 수정할 수있는 작업 s3:PutObject, s3:DeleteBucket
Permissions management 리소스에 대한 사용 권한을 부여하거나 수정할 수있는 작업 s3:PutBucketPolicy

참고: 모든 AWS 서비스가 같은 접근 수준 작업을 제공하는 것은 아닙니다.

아래 스크린샷에서 S3의 접근 수준은 전체(Full) 접근 가능입니다. 즉, IAM 정책이 S3 목록 보기, 읽기, 쓰기 및 권한 관리 접근 수준의 모든 작업을 허용한다는 것을 의미합니다. EC2에 대한 접근 수준은 Full: List, Read 및 Limited: Write입니다. 즉, 정책이 List 및 Read 접근 수준의 모든 동작을 허용하지만, 쓰기 접근 수준 동작의 일부만 허용합니다. 정책 요약에서 서비스를 선택하여 정책에 정의 된 특정 작업을 볼 수 있습니다.

접근 요약 세부적으로 보기
IAM 콘솔에서 정책 요약을 살펴 보겠습니다. Alice라는 사용자는 데이터를 분석하고 재무팀에 대한 분기 보고서를 생성하는 개발자입니다. 그에게 필요한 권한을 부여하기 위해 Data_Analytics IAM 그룹에 추가했습니다.

사용자 Alice에 첨부 된 정책을 보려면 IAM 콘솔 사용자 페이지에서 사용자 이름을 선택하여 사용자 페이지로 이동합니다. 아래 스크린 샷은 Alice에게 3 가지 정책이 첨부되어 있음을 보여줍니다.

이제 Data_Analytics 정책에 정의 된 사용 권한을 검토해 봅니다. 먼저 여러 가지 보기를 비교할 수 있도록 먼저 JSON 구문을 살펴 보겠습니다.

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Action": [
            "autoscaling:*",
            "ec2:CancelSpotInstanceRequests",
            "ec2:CancelSpotFleetRequests",
            "ec2:CreateTags",
            "ec2:DeleteTags",
            "ec2:Describe*",
            "ec2:ModifyImageAttribute",
            "ec2:ModifyInstanceAttribute",
            "ec2:ModifySpotFleetRequest",
            "ec2:RequestSpotInstances",
            "ec2:RequestSpotFleet",
            "elasticmapreduce:*",
            "es:Describe*",
            "es:List*",
            "es:Update*",
            "es:Add*",
            "es:Create*",
            "es:Delete*",
            "es:Remove*",
            "lambda:Create*",
            "lambda:Delete*",
            "lambda:Get*",
            "lambda:InvokeFunction",
            "lambda:Update*",
            "lambda:List*"
        ],
        "Resource": "*"
    },

    {
        "Effect": "Allow",
        "Action": [
            "s3:ListBucket",
            "s3:GetObject",
            "s3:PutObject",
            "s3:PutBucketPolicy"
        ],
        "Resource": [
            "arn:aws:s3:::DataTeam"
        ],
        "Condition": {
            "StringLike": {
                "s3:prefix": [
                    "Sales/*"
                ]
            }
        }
    }, 
	{
        "Effect": "Allow",
        "Action": [
            "elasticfilesystem:*"
        ],
        "Resource": [
            "arn:aws:elasticfilesystem:*:111122223333:file-system/2017sales"
        ]
    }, 
	{
        "Effect": "Allow",
        "Action": [
            "rds:*"
        ],
         "Resource": [
            "arn:aws:rds:*:111122223333:db/mySQL_Instance"
        ]
    }, 
	{
        "Effect": "Allow",
        "Action": [
            "dynamodb:*"
         ],
        "Resource": [
            "arn:aws:dynamodb:*:111122223333:table/Sales_2017Annual"
        ]
    }, 
	{
        "Effect": "Allow",
        "Action": [
            "iam:GetInstanceProfile",
            "iam:GetRole",
            "iam:GetPolicy",
            "iam:GetPolicyVersion",
            "iam:ListRoles"
        ],
        "Condition": {
            "IpAddress": {
                "aws:SourceIp": "192.0.0.8"
            }
        },
        "Resource": [
            "*"
        ]
    }
  ]
}

정책 요약을 보려면 정책 이름을 선택하여 정책 페이지로 이동하거나, 정책 이름 옆에 있는 화살표를 선택하면 Alice의 사용자 페이지에서 정책 요약이 확장됩니다. 아래 스크린샷은 Alice에 첨부 된 Data_Analytics 정책의 정책 요약을 보여줍니다.

이 정책 요약을 보면 Alice가 다양한 접근 수준을 가진 여러 서비스에 접근할 수 있음을 한 눈에 알 수 있습니다. Amazon EMR에 대한 모든 접근 권한이 있지만 IAM에 대한 제한된 목록 및 제한된 읽기 권한만 있습니다. 또한 각 서비스에 부여되는 리소스 및 조건에 대한 상위 수준의 요약을 볼 수 있습니다. 이 정책에서 Alice는 Amazon EFS의 2017sales 파일 시스템과 하나의 Amazon RDS 인스턴스에만 접근할 수 있습니다. 또한, 여러 Amazon S3 버킷 및 Amazon DynamoDB 테이블에 접근할 수 있습니다. 요청 조건 열을 보면, Alice가 특정 IP 범위에서만 IAM에 접근할 수 있습니다. 리소스 및 요청 조건에 대한 자세한 내용은Understanding Policy Summaries in the AWS Management Console 설명서를 참조하십시오.

정책 요약에서 서비스에 부여 된 특정 작업을 보려면 서비스 이름을 선택합니다. 예를 들어, Elasticsearch를 선택하면 아래 스크린 샷과 같이 접근 수준별로 정리 된 모든 작업을 볼 수 있습니다. 이 경우 Alice는 모든 Amazon ES 리소스에 접근할 수 있으며 요청(request) 조건은 가지고 있지 않습니다.

예외사항
복잡하거나 인식 할 수 없는 작업이 포함 된 정책의 경우, 정책 요약은 사람이 읽을 수 있는 단순한 테이블을 생성하지 못할 수 있습니다. 이러한 경우, 정책 요약 없이 JSON 정책을 계속 보여주게 됩니다.Deny 문을 포함하는 정책의 경우, 정책이 명시적으로 거부하는 사용 권한을 보여주는 별도의 테이블을 보여줍니다. 이 설명서에는 Allow 문과 Deny 문을 모두 포함하는 정책 요약 예제가 나와 있습니다.

AWS 계정의 정책 요약을 보려면 IAM 콘솔에 로그인하고 IAM 콘솔의 정책 페이지 또는 사용자 페이지의 Permissions 탭에서 관리되는 정책으로 이동하시기 바랍니다. 정책 요약을 통해 전체 권한 또는 사용 권한 관리 권한을 가진 사용자를 빠르게 식별하는 등의 특정 권한을 쉽게 검색 할 수 있습니다. 또한 정책을 비교하여 조건을 정의하는 정책을 결정하거나보다 안전한 보안 상태를 위해 리소스를 지정할 수 있습니다.

이 게시물에 대한 의견이나 질문이나 제안 사항이 있으면 IAM 포럼에서 문의해 주시기 바랍니다.

– Joy

이 글은 AWS Security Blog의 Move Over JSON – Policy Summaries Make Understanding IAM Policies Easier의 한국어 번역입니다.

운영 중인 EC2 인스턴스에 IAM 역할 연결하기

AWS Identity and Access Management (IAM)의 역할을 통해 Amazon EC2 에서 실행되는 응용 프로그램이 자동 생성, 배포되는 임시 보안 자격 증명을 사용할 수 있습니다 . 임시 자격 증명을 사용하는 것은 IAM 모범 사례로서 인스턴스에서 직접 키 관리를 하지 않아도 됩니다.

2017-02-aws-iam-ec2-instance

즉, EC2 IAM 역할 적용 기능을 사용하여 장기적인 AWS 액세스 키(Access Key)를 수동 혹은 프로그램에서 직접 관리 할 필요가 없습니다. 얼마 전, IAM 역할을 통해 기존 EC2 인스턴스 응용 프로그램에서 AWS에서 제공하는 임시 보안 자격 증명을 사용할 수 있게 되었습니다. 또한 기존 EC2 인스턴스에 첨부 되어있는 IAM 역할을 변경할 수 있습니다.

이 글에서는 AWS CLI를 사용하여 기존 EC2 인스턴스에 IAM 역할을 손쉽게 변경하는 방법을 소개합니다. 아래는 이 글의 주요 순서입니다.

  1. IAM 역할 생성 하기
  2. EC2 인스턴스에 신규 IAM 역할 추가하기
  3. EC2 인스턴스에서 기존 IAM 역할 변경하기

이 글에서는 새로 만든 IAM 역할을 “YourNewRole”라고합니다. 이 역할과 연관된 인스턴스 프로파일을 “YourNewRole-Instance-Profile” 기존 인스턴스를 “YourInstanceId”라고 하겠습니다. 여기에서는 AWS 명령 줄 인터페이스 (CLI) 설정을 완료하고, IAM 역할을 만들 권한 및 EC2 API를 호출 권한을 가지고 있음을 전제로 하고 있습니다.

1. IAM 역할 생성 하기

참고 : 기존 IAM 역할을 연결할 경우, 이 글 아래의 “EC2 인스턴스에 신규 IAM 역할 추가하기”를 보시기 바랍니다. 또한, AWS 관리 콘솔을 사용하여 IAM 역할을 생성하고 진행하면 됩니다.

AWS CLI에서 IAM 역할을 생성하기 전에 신뢰 정책(Trust policy)을 작성해야합니다. 신뢰 정책은 EC2 등의 AWS 서비스가 응용 프로그램 대신 IAM 역할을 맡도록 허용합니다. 신뢰 정책을 만들려면, 아래 정책을 복사하여 YourNewRole-Trust-Policy.json로 저장 한 텍스트 파일에 붙여 넣습니다.

Json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

신뢰 정책을 만들면 기존 EC2 인스턴스에 연결할 수 있는 IAM 역할을 만들 준비가 되었습니다.

AWS CLI에서 IAM 역할을 만들기:

  1. AWS CLI에서 create-role 명령을 호출하여,  YourNewRole-Trust-Policy.json을 기반으로 YourNewRole이라는 IAM 역할을 생성합니다.
    $aws iam create-role --role-name YourNewRole --assume-role-policy-document file://YourNewRole-Trust-Policy.json
    
  2. 만들어진 IAM 역할에 계정 자원에 대한 접근 권한을 부여하려면, attach-role-policy 명령을 호출합니다. 아래 는 애플리케이션이 Amazon S3 버킷의객체에 대한 읽기 권한이 필요한 경우입니다. 따라서, AWS 관리 정책 중 하나인 AmazonS3ReadOnlyAccess을 사용합니다. AWS 관리 정책에 대한 자세한 내용은 “관리 정책 기술 문서“를 참조하십시오.
    $aws iam attach-role-policy --role-name YourNewRole --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess
  3. create-instance-profile 명령 및 add-role-to-instance-profile 명령을 실행하여, IAM 인스턴스 프로파일 “YourNewRole-Instance-Profile“을 만듭니다. 인스턴스 프로파일을 통해 EC2는 IAM 역할 “YourNewRole“을 EC2 인스턴스에 추가할 수 있습니다. 자세한 내용은 “인스턴스 프로파일 사용“을 참조하십시오.
    $aws iam create-instance-profile --instance-profile-name YourNewRole-Instance-Profile
    $aws iam add-role-to-instance-profile --role-name YourNewRole --instance-profile-name YourNewRole-Instance-Profile

“YourNewRole”라는 IAM 역할을 성공적으로 만들었습니다.

2. EC2 인스턴스에 신규 IAM 역할 추가하기

이제 YourNewRole이라는 IAM 역할을 EC2 인스턴스 YourInstanceId에 연결할 준비가 되었습니다. 이제 추가해 보겠습니다.

  1. associate-iam-instance-profile 명령을 호출하여, 새로 생성 된 IAM 역할 “YourNewRole-Instance-Profile”, “YourNewRole” 인스턴스 프로파일을 EC2 인스턴스 “YourInstanceId”에 연결합니다.
    $aws ec2 associate-iam-instance-profile --instance-id YourInstanceId --iam-instance-profile Name=YourNewRole-Instance-Profile
  2. describe-iam-instance-profile-association 명령을 호출하여 IAM 역할이 제대로 인스턴스에 연결되어 있는지 확인합니다.
    $aws ec2 describe-iam-instance-profile-associations
  3. 이제 IAM 역할을 사용하여 AWS 자원에 접근할 수 있도록 애플리케이션을 업데이트하고, 인스턴스에서 보안 키를 삭제할 수 있습니다.

3. EC2 인스턴스에서 기존 IAM 역할 변경하기

기존 IAM 역할의 요구 사항이 변경되어, 기존 EC2 인스턴스에 부여 된 권한을 변경할 필요가 있는 경우 IAM 역할과 관련된 정책을 바꿀 수 있습니다. 새로 변경된 IAM 역할을 사용하는 다른 EC2 인스턴스의 권한도 변경됩니다.대신 replace-iam-instance-profile-association 명령을 호출하여 현재 연결되어있는 IAM 역할 “YourNewRole”다른 IAM 역할을 대체 할 수 있습니다. 아래 예제에서는 “YourCurrentAssociation-id”를 사용하여, 현재 iam-instance-profile-association 인스턴스를 나타내고, “YourReplacementRole-Instance-Profile”을 사용하여 인스턴스에 연결할 대체 인스턴스 프로파일을 나타냅니다. 이 자리 표시자를 적절한 association-id와 계정의 IAM 인스턴스 프로필 이름을 변경하십시오.

$aws ec2 replace-iam-instance-profile-association --association-id YourCurrentAssociation-id --iam-instance-profile Name=YourReplacementRole-Instance-Profile 

참고 : YourCurrentAssociation-id는 describe-iam-instance-profile-associations를 호출하여 얻을 수 있습니다.

이 글에서는 EC2 인스턴스를 다시 시작하지 않고, 기존 EC2 인스턴스에 IAM 역할을 추가 혹은 변경하여 애플리케이션이 AWS에서 제공하는 임시 보안 자격 증명을 사용할 수 있습니다. 중요한 애플리케이션 중단 없이 EC2 인스턴스에 연결된 IAM 역할을 대체 할 수 있습니다.

이 게시물에 대한 의견이나 질문이나 제안이 있으시면, IAM 포럼에서 의견 주시기 바랍니다.

– Apurv;

이 글은 New! Attach an AWS IAM Role to an Existing Amazon EC2 Instance by Using the AWS CLI의 한국어 번역입니다.

AWS IAM 서비스 최종 접근 데이터 기능, 서울 리전 출시

지난해 말 AWS Identity and Access Management (IAM)에서 IAM 엔티티 (사용자, 그룹, 역할)가 AWS 서비스에 마지막으로 접근한 시간을 표시하는 기능인 Service Last Accessed Data 를 출시했습니다. 오늘부터 서울 리전에서 사용할 수 있습니다.

이 기능은 최소한 권한 부여에 크게 도움이 되는 기능입니다. IAM 사용자에게 불필요한 권한을 주지 않고, 최소한의 권한을 주는 것은 보안에 매우 중요한 요소입니다.

IAM 서비스에서 Access Advisor탭을 누르면, 아래 정보를 보실 수 있습니다.

  • 접근 정책에 대한 서비스 권한 목록
  • 사용자, 그룹 및 정책에 대한 서비스 권한 목록
  • 마지막으로 접근한 시간

아래 스크린샷은 마지막으로 접근한 서비스 목록에 대한 예제입니다.

Service Last Accessed Data의 정보가 추가되어 어떤 권한을 제거 할 수 있는지를보다 쉽게​​ 식별 할 수있게되었습니다. IAM 엔티티와 정책에 대해 다음과 같은 정보에 액세스 할 수 있습니다 :

  • 접근 정책이나 그룹에 관련된 모든 IAM 사용자 및 역할 Last Accessed Data
  • 기존 IAM 사용자, 역할 그룹에 서비스 권한을 부여하는 모든 정책

이러한 상세 데이터에 의해 접근 패턴과 정책 구성을 보다 쉽게​​ 이해할 수 있습니다. 결과적으로 더 나은 정보를 바탕으로 권한 관리 결정을 내릴 수 있습니다.

Service Last Accessed Data 활용한 IAM 권한 보기
여러분이 AWS 내부 사용자 및 클라우드 보안을 관리하는 IAM의 관리자라면, IAM 사용자 권한 및 역할에 대한 정책이 얼마나 넓게 적용되어 있는지를 알고 싶을 것입니다.

지금까지는 관리 정책의 Access Advisor 탭에서는 서비스가 언제 마지막으로 접근했는지 AWS CloudTrail 로그를 검색하지 않더라도 Access by Entities 열의 링크를 클릭하여 어떤 사용자 또는 역할이 서비스에 마지막으로 접근했는지, 해당 서비스와 관련된 모든 사용자 및 역할이 언제 마지막으로 접근했는지 바로 볼 수있게되었습니다.

예를 들어, 다음 스크린 샷은있는 관리 정책에서 부여 된 Amazon EC2의 권한에 대한 정보를 볼 수 있습니다. IAM 정책을 연결한 모든 사용자 및 역할이 실제로 EC2에 접근하는 것은 아닙니다. 즉, 사용자 및 역할 중 일부는 취소 가능한 과대 권한을 가지고 있는지를 보여줍니다.

Access Advisor를 통한 IAM 권한 변경하기
Service Last Accessed Data를 참조 후, 사용자 및 역할에서 필요없는 정책을 삭제하거나 분리하거나 싶을 경우, Policies Granting Permissions 서비스 권한 링크를 클릭하십시오. 그러면 AWS 관리 정책 및 IAM 그룹에서 상속된 정책이 표시됩니다. 대화 상자에서 정책의 이름을 클릭하여 해당 정책을 참조 할 수 쉽게 변경할 수 있습니다.

아래 화면은 IAM 사용자에게 부여되는 EC2에 대한 권한의 소스를 보여줍니다. 여러 관리용 인라인 정책이 정의되어 있고, 일부 정책을 삭제하거나 통합하는 것이 적절하다는 것을 시사하고 있습니다.

Service Last Accessed Data에 대한 자세한 사항은 Remove Unnecessary Permissions in Your IAM Policies by Using Service Last Accessed Data, Now Available: Get Even More Details from Service Last Accessed Data 혹은 Remove Unnecessary Permissions in Your IAM Policies by Using Service Last Accessed Data 블로그 글을 참고하시기 바랍니다.

AWS 관리 콘솔에서 교차 계정 접근(Cross-Accounts Access) 활용하기

AWS는 클라우드에서 보안을 최우선으로 하며, 다양한 보안 관련 서비스와 기능 및 선택 사항을 제공하고 있습니다. 특히, 사용자 권한 관리는 AWS IAM(Identity and Access Management)이라는 서비스를 통해 구성하고 관리하게 됩니다. IAM은 다양한 기능을 가지고 AWS 리소스를 사용하는데, API 수준의 세부적인(fine-grained) 접근 제어를 지원합니다.

IAM 서비스 및 교차 계정 접근 제어
IAM 기능을 잘 활용할 경우 고객 서비스 운영 중 특정 사용자나 관리자 또는 개발자의 권한을 모두 구분하여 제어할 수 있습니다. 따라서, 잘못된 운영이나 실수를 권한을 제한하여 막을 수 있고, 필요에 따라서 제한적으로 가능하게 할 수 있습니다.

예를 들어 네트워크 관리자에게 데이타베이스에 대한 접근 운영 권한을 주는 것은 좋은 방법이 아닐 것입니다. 이러한 제한은 사고를 방지할 수도 있으며, 경우에 따라 API 권한(credential)을 획득한 악의적인 접근을 IAM을 통해 원천적으로 차단할 수도 있습니다.

IAM은 사용자(User, 이하 User)라는 개념과 역할(Role, 이하 Role)이라는 개념을 동시에 제공합니다. User는 특정 권한을 가진 사용자를 뜻하며, 별도의 URL을 통해 AWS 관리 콘솔에 직접 로그인할 수 있는 사용자(사람)을 의미합니다. 역할의 경우는 특정 권한을 특정 서비스나 사용자에 부여할 수 있으며, 변경도 가능합니다. 뿐만 아니라, Role은 password나 access key가 없어 상대적으로 보다 안전하게 사용이 가능하며, User는 Role의 권한을 받아 AWS 리소스에 편리하고 안전하게 접근이 가능합니다.

다만, 여러 User가 복수 계정에서 서로 다른 Role을 손쉽게 이동하면서 관리해야 할 경우를 위해 지난 해 교차 계정 접근 제어(Cross-Account Access) 기능을 출시하였습니다. 이를 통해 AWS 관리 콘솔에서 Role 전환을 쉽게 할 수 있게 하여, User가 여러 AWS 계정 (또는 여러 Role) 환경에서 효과적으로 일을 더 쉽게 할 수 있게 됩니다.

또한, 관리자가 허용한 특정 User에 대해 다른 사용자 이름과 암호를 입력(혹은 기억하는)없이 다른 계정을 관리하기 위해 역할을 전환할 수 있습니다. 위의 설명한 교차 계정 접근 제어는 API로도 가능하나, 오늘은 AWS 관리 콘솔에서도 어떻게 설정하는지 간단한 예를 들어 설명드리겠습니다.

IAM User와 Role 생성하기
우선 AWS IAM에서 Chulsoo라는 User를 생성합니다. User를 생성하고 해당 User 가 AWS 관리 콘솔에 로그인 하기 위해서는 암호 설정이 필요합니다.

User를 생성한 후에 Chulsoo를 선택하여 암호를 설정합니다.

Chulsoo는 현재 아무런 권한이 없으므로 암호를 설정한 후에 AWS 관리 콘솔에 로그인은 가능하나, 다른 작업을 전혀 할 수 없습니다.

이제 Chulsoo라는 User에게 VPC 관련 설정을 할 수 있는 권한을 주고 싶다면, 권한을 가진 Role을 생성하여 진행 할 수 있습니다. IAM 메뉴에서 Role을 선택하고 Create new Role을 선택합니다.

여기서는 NetworkAdmin 이라는 이름으로 Role을 생성합니다. Role을 생성한 후 해당 Role을 다른 AWS 계정 또는 현재 사용중인 AWS 계정에게 권한을 위임 가능하게 하려면, Role for Cross-Account Access를 선택하여 Provide access between AWS accounts you own을 선택합니다. 즉, 해당 Role을 역서 선택한 Account에게 권한을 위임할 수 있도록 허가하는 것입니다.

위와 같이 선택하여 진행하면 아래와 같이 계정 ID(Account ID)를 입력하는 곳으로 넘어갑니다. 본인의 계정 ID를 안다면 입력하고, 만약 모른다면 Console에서 My Account메뉴에서 본인의 Account ID를 확인할 수 있습니다.

Role과 동일한 Account 인 경우에도 입력이 필요하므로 꼭 입력을 하여 진행합니다. 입력 후 진행하면 이제 해당 Role이 가질 Policy를 선택합니다. 이 예제에서는 NetworkAdmin으로 이름에 맞게 VPC권한을 선택합니다.

Policy 선택 후 진행하면 아래와 같이 설정된 설정한 Role에 대한 정보와 유용하게 사용될 Switch role을 위한 링크가 제공됩니다.

User에 Role 권한 추가하기
다음으로 특정 User 역시 Role을 사용할 수 있도록 권한을 주어야만 합니다. 즉, Chulsoo는 NetworkAdmin Role을 실행할 수 있는(Assume) 권한이 있어야만 합니다. 위 단계에서 생성된 Role ARN을 기억하여 Chulsoo의 권한 설정을 진행합니다.

IAM의 User에서 Chulsoo를 선택하고 Permissions에서 Inline Policies를 선택합니다. IAM Policy 문법을 모른다면 Policy Generator를 선택하면 쉽게 Policy를 구성할 수 있습니다.

Policy Generator를 선택 후 아래와 같이 입력합니다. 풀어 설명하면 권한을 허가(Allow)하는데 해당 허가하는 AWS Security Token Service의 AssumeRole API를 Amazon Resource Name(ARN)에 대해서 허가한다는 정책입니다.

Review Policy에서 구성된 Policy를 확인할 수 있습니다. 아래와 같은 정책이 생성되어 해당 User에 적용됩니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Stmt1458698661000",
            "Effect": "Allow",
            "Action": [
                "sts:AssumeRole"
            ],
            "Resource": [
                "arn:aws:iam::XXXXXXXXXXXX:role/NetworkAdmin"
            ]
        }
    ]
}

Switch Role 사용하기
이제 User와 Role이 모두 생성되었으니, 해당 User로 AWS 관리 콘솔에 로그인합니다. User로 로그인하기 위해서는 별도 IAM User sign-in 주소를 사용합니다. IAM 대시 보드에서 주소를 확인할 수 있습니다. IAM 사용자들이 기억하기 쉬운 도메인 주소로 재설정한 후, 북마크 해서 사용할 수 있습니다.

웹 브라우저에서 해당 주소를 입력하고 앞에서 생성한 Chulsoo와 지정한 암호를 입력하여 로그인합니다. 로그인을 하였으나, 현재 아무런 권한이 없습니다. 앞에서 생성한 NetworkAdmin을 권한을 등록 사용할 수 있도록 switch role in the console 주소를 이용합니다.

만약 업무에서는 IAM을 관리하는 관리자가 요청된 권한을 가진 Role을 생성하고 switch role을 위한 아래 링크 주소를 User에게 주는 방식으로 쉽게 관리가 가능합니다.

Chulsoo user로 로그인 한 후에 위 주소를 브라우져에 입력하면 아래와 같이 Switch Role 지정 화면으로 이어집니다.

Switch Role 버튼을 누르면 바로 해당 Role로 AWS 관리 콘솔에 로그인이 됩니다. Role로 지정한 색과 이름이 오른쪽 윗 부분에 쉽게 표시됩니다.

VPCFullAccess 권한을 가진 NetworkAdmin Role을 가지고 있으므로, 다른 AWS Service에서는 전혀 작업을 할 수 없으나, VPC 메뉴에서는 모든 관련 작업을 할 수 있습니다.

예를 들어 RDS Instance를 확인하려 할 경우 권한이 없는 에러가 발생합니다.

다른 Role로 전환하기
위에서 NetworkAdmin Role을 만든 것과 동일한 방법으로 RDS만 관리할 수 있는 Role을 생성하여 동일하게 Chulsoo user가 사용할 수 있도록 추가합니다.

여기서는 RDSAdmin Role을 생성하여 구성하였습니다. 동일한 방법으로 Switch Role을 하여 등록하면 아래와 같이 RDSAdmin Role로 변경된 것을 확인할 수 있습니다.

이제 RDS메뉴로 가면 DB를 생성할 수도 있고, RDS instance도 확인이 가능합니다.

위와 같이 구성하면 이제 Chulsoo user를 NetworkAdmin과 RDSAdmin을 자유롭게 변경하면서 작업을 할 수 있습니다. 메뉴에서 원하는 Role을 선택하면 바로 해당 Role로 전환이 됩니다.

이처럼 교차 계정 접근를 통해 Role을 사용하면 동일 AWS 계정내에서는 제한적인 권한으로 안전하게 AWS 서비스를 운영하거나 사용할 수 있고, 다른 Account ID를 통해 다른 사용자에게 권한을 위임할 수도 있습니다. IAM User Credential을 배포하는 방식이 아닌 Role을 배포하는 방식을 활용하면 보다 안전하게 권한 관리를 할 수 있으며, 보안 입장에서도 편리하게 운영이 가능합니다. Dev/Test/Prod 환경에서 위와 같은 User/Role을 이용하여 AWS를 안전하게 사용하시길 권고 드립니다.

더 자세한 정보는 How to Enable Cross-Account Access to the AWS Management Console(영문)이나 도움말 – IAM 역할과 리소스 기반 정책의 차이을 참고하시기 바랍니다.

본 글은 아마존웹서비스 코리아의 솔루션즈 아키텍트가 국내 고객을 위해 전해 드리는 AWS 활용 기술 팁을 보내드리는 코너로서, 이번 글은 김일호 솔루션즈 아키텍트께서 작성해주셨습니다.