DEV

AWS 키, 하드코딩만 안 하면 OK?

왜 Access Key 사용을 지양해야 하고, IAM Role 기반 자격 증명이 어떻게 작동하는지에 대해

jiheon2234

— 4 min read
yml에서 환경변수를 참조해 AWS키를 읽고 있는 코드
이거 어서 많이 본 것 같죠??

들어가며

AWS는 클라우드 시장 점유율 1위답게, 초보자도 관련 예제를 쉽게 찾아볼 수 있어요
(특히 Spring 예제는 정말 많아요).

그런데, 대부분의 예제에서는
위와 같이 IAM 사용자의 Access Key를 직접 코드에 넣고 있는데
이건 AWS에서 공식적으로 지양하는 방법이에요!!

그러면 지금부터 어떤 AWS 자격 증명 방식이 권장되는지,
나아가 AWS가 자격 증명을 어떻게 탐색하는지도 함께 알아보죠.

Access Key를 사용하지 말아요

We strongly recommend that you use temporary credentials provided by IAM roles and federated users instead of the long-term credentials provided by IAM users and access keys. (Aws Security Best Practices)

결론부터 말하면, 어쩔 수 없는 경우를 제외하고 Access Key 자체를 사용하지 않는 방식이 권장되요.

Access Key를 사용하면

  • 기본적으로 영구적이라, 유출시 피해가 걷잡을 수 없어요.
  • Git등에 섞여 들어갈 위험이 커요.
  • 사람이 직접 관리해야 하는 근본적 한계가 있어요.

그러면 뭘 써야 할까요?

EC2, ECS, Lambda 같은 AWS 리소스 위에서 돌아가는 애플리케이션일 경우,
리소스의 IAM Role 사용이 절대적으로 권장돼요.
AWS IAM User 대신, AWS 리소스 자체에 붙는 IAM Role을 만드는거에요.

EC2->Instance profile
ECS-> Task Role
Lambda -> Execution Role
각각 세부적인 내용은 다르지만, 간단하게 설명하면:

신뢰 주체가 STS의 AssumeRole을 사용해
임시 키 (AccessKey, Secret, SessionToken)를 얻고,
이걸 AWS SDK가 자동으로 갱신해줘요
보안도 뛰어나고, 관리도 편하겠죠?

로컬에선 어떻게 하죠?

로컬에서는, 보통 ~/.aws 폴더를 사용해서
프로파일 기반으로 자격 증명을 분리하고, 일관되게 사용하는 방식이 권장되요.
내용이 조금 다양하고 많아서, 자세한 건 문서를 참조하시는걸 추천드릴게요.

저 설정만으로 된다고요? [자격 증명 체인]

@Bean
public S3Client s3client() {
      S3Client s3 = S3Client.builder()
              .region(Region.AP_NORTHEAST_2)
              .credentialsProvider(
                  StaticCredentialsProvider.create(
                  AwsBasicCredentials.create("accessKey", "secretKey") //
                ))
              .build();
}

accessKey,secretKey는 어디서??

네, AWS의 자격 증명 체인(Credential Provider Chain)을 사용하면 가능해요
AWS는 기본적으로 대부분의 SDK에서 표준화된 자격 증명 체인을 지원하는데,
JAVA를 기준으로 살펴볼게요.

credentialsProvider(DefaultCredentialsProvider.create()) //생략도 가능

AWS 기본 자격 증명 체인 사용

코드를 살펴보면, 6개의AwsCredentialsProvider 구현체를 통해 가장 먼저 성공하는 credentials를 가져오게 되어 있는데,
간단히 정리하면 다음과 같아요:

  1. SystemPropertyCredentialsProvider
    -> JVM 시스템 변수에서
  2. EnvironmentVariableCredentialsProvider
    ->환경 변수에서
  3. WebIdentityTokenFileCredentialsProvider
    -> EKS나, OIDC 등 페더레이션 플로우시
  4. ProfileCredentialsProvider
    -> ~/.aws 경로에서
  5. ContainerCredentialsProvide
    -> 컨테이너의 메타데이터 에서 (ECS등)
  6. InstanceProfileCredentialsProvider
    -> IMDS를 이용해 EC2 인스턴스 메타데이터에서

이 중 앞서 말한 리소스의 IAM ROLE을 사용하는 방식인 5번과 6번은 STS 기반의 임시 자격 증명을 자동으로 갱신하므로,
보안성과 관리 편의성 측면에서 매우 유리해요.

디버깅해보실 분만 클릭

주의 : providerChain으로 LazyAwsCredentialsProvider가 사용되기때문에, 실제로 자격증명이 필요한 순간 체인이 초기화되어 완전한 디버깅이 가능해요.

3줄요약

  1. Access Key는 가능한 한 사용하지 말고, IAM Role을 사용하자
  2. SDK가 기본으로 지원하는 자격 증명 체인을 따라가자
  3. 블로그 예제만 따라하지 말고,공식 문서를 읽어보자

Read more