[AWS] aws sts & assume role - (1)

https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/id_credentials_temp.html

IAM의 임시 보안 자격 증명 - AWS Identity and Access Management

 

STS (Security Token Service)

AWS에서 보안 토큰을 생성하는 서비스이다.

STS를 사용하면 AWS 리소스에 대한 액세스를 제어할 수 있는 임시 보안 자격 증명을 생성하여 사용자에게 제공할 수 있다. 

위 사진을 보면 developer가 aws sts로부터 임시 access key를 부여 받고, applicable policies에 접근할 수 있게 된다.

 

임시 보안 자격 증명은 AWS STS에 의해 생성되며, https://sts.amazonaws.com에 단일 엔드포인트가 있는 global 서비스이다.

임시 자격 증명은 교차 계정 간 리소스 접근 제어, IAM Role 기반 제어 등에서 유용하게 사용할 수 있다.

 

 

 

Assume Role

IAM Role은 일시적으로 권한을 가질 수 있는 IAM 기능이다. Assume(취하다, 갖다) 즉, Role을 취한다는 의미이다. 

role을 사용하려면 해당 role을 사용할 수 있는 보안주체를 반드시 지정해줘야 한다. 이걸 aws에선 신뢰 관계(trust-relationship)라 한다.

 

신뢰관계는 user, role, service 등 다양하게 맺을 수 있고, 신뢰 관계를 맺은 주체가 role을 사용하게 해주는게 assume이다.

 

 

 

Assume Role 테스트

Assume Role은 설명보다 간단한 예시로 쉽게 이해할 수 있다. 

 

hb, hyeongbin이란 사용자와 poc, security s3, 그리고 s3에 접근할 수 있는 role이 있다.

각 사용자엔 아무런 권한이 없는 상태이며, hb 사용자만 role을 통해 s3에 접근할 수 있게 세팅해보자 

 

우선 s3를 조회할 수 있는 policy와 정책을 연결한 role을 먼저 생성해주자

# (s3-policy)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Allow",
            "Effect": "Allow",
            "Action": [
                "s3:*"
            ],
            "Resource": "*"
        }
    ]
}

 

테스트하기 위해 Action, Resource는 *(모든 권한)으로 주었다. 이제 이 policy와 role을 연결하고 신뢰관계를 아래와 같이 수정해주자

Principal에서 Role에 Assume할 수 있는 주체의 arn을 명시해주면 된다. 물론 user 외에도 role, service 모두 가능하며, Condition으로 디테일하게 필터링도 가능하다. (위 사진에 hyeongbin은 오타이며 hb이라고 가정)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "UsePrincipalArnInsteadOfNotPrincipalWithDeny",
      "Effect": "Deny",
      "Action": "s3:*",
      "Principal": "*",
      "Resource": [
        "arn:aws:s3:::BUCKETNAME/*",
        "arn:aws:s3:::BUCKETNAME"
      ],
      "Condition": {
        "ArnNotEquals": {
          "aws:PrincipalArn": "arn:aws:iam::111122223333:user/hb"
        }
      }
    }
  ]
}

 

이런 식으로 Condition에 있는 해당 arn을 가진 사용자와 일치하지 않는 arn에 대해서 모두 차단하겠다는 의미이다.

즉, 해당 신뢰 관계는 hb 사용자만 s3에 접근이 가능하게 하겠단 뜻이로 위에 신뢰관계와 동일한 정책이라고 보면 된다.

 

이제 hb 계정에 access key를 발급 받고 자격 증명을 해둔 상태에서 s3를 조회해자

 

권한이 없으므로 당연히 조회되지 않는다. 위에서 생성한 role에 assume해서 sts을 받아오자

 

assume-role에 성공하면 2번째와 사진과 같이 Credentials에 Accesskey, SecretAccesskey, SessionToken이 조회된다.

참고로 현재 role sts 지속 시간은 1시간이므로 1시간 뒤엔 사용할 수 없다. (최대 12시간으로 조정 가능)

 

sts assume-role로 얻은 credentials로 assume이란 profile을 생성해주었다. 이제 해당 profile로 s3를 조회해보자

 

s3를 조회할 수 있는 권한을 가진 role에 assume하여 얻은 sts을 통해 조회해보면 s3가 잘 조회되는걸 볼 수 있다. 이처럼 assume-role을 사용하면 직접적으로 권한이 없더라도, 임시 자격증명을 통해 해당 리소스에 접근할 수 있다.

 

각 사용자에게 직접 권한을 할당하는 경우 키가 유출되면 매우 큰 보안사고로 이어질 수 있으니, 웬만하면 role을 기반으로 리소스 접근을 제어하는게 좋다.