설명
실제 AWS 비밀정보를 EC2 user_data에 넣으면 플레이북이나 사용자 데이터에 접근할 수 있는 사람에게 노출될 수 있습니다. 장기 액세스 키 대신 필요한 권한만 가진 인스턴스 역할과 임시 자격 증명을 사용하세요.
액세스 키 ID만으로 AWS 요청을 인증할 수는 없습니다. 비밀 액세스 키가 함께 필요하며 임시 자격 증명에는 세션 토큰도 필요합니다. 의심되는 값이 문서의 예시인지 실제 자격 증명인지 확인하되, 실제 비밀정보가 노출되었다면 파일에서 삭제하는 것만으로 대응을 끝내서는 안 됩니다.
잠재적 영향
- 유효한 자격 증명 전체가 노출되면 해당 권한 범위에서 원치 않는 AWS 요청에 사용될 수 있습니다.
- 저장소 이력, 사용자 데이터나 배포 기록에 사본이 남을 수 있으며, 공유 키를 교체할 때 의존하는 작업도 수정해야 할 수 있습니다.
해결 방법
- 실제 비밀정보를
user_data에서 제거하고 최소 권한의 IAM 역할을 인스턴스 프로파일로 연결하세요. 애플리케이션은 지원되는 SDK의 기본 자격 증명 공급자를 통해 임시 자격 증명을 사용하도록 구성하세요. - 실제로 노출된 유효한 키는 의존 작업을 확인하면서 신속히 비활성화하거나 폐기하고 교체하세요. 현재 파일뿐 아니라 저장소 이력과 기존 사용자 데이터의 사본도 확인하세요.
- 관련 접근 기록을 조사하고 새 인증 방식으로 필요한 작업이 계속 실행되는지 검증하세요.
예시
키 문자열은 공개된 문서 예시이며 실제 자격 증명이 아닙니다. AMI, 인스턴스 유형과 서브넷은 환경에 맞게 지정하세요. 변경 후에는 필요한 역할이 포함된 인스턴스 프로파일을 별도로 준비하고, 배포 주체에도 이를 연결할 권한을 부여해야 합니다.
변경 전
yaml
- name: start an instance
community.aws.ec2_instance:
name: credential-example
image_id: "{{ ami_id }}"
instance_type: "{{ instance_type }}"
vpc_subnet_id: "{{ subnet_id }}"
user_data: |
#!/bin/bash
export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
초기화 스크립트에 키 쌍을 직접 넣는 형태입니다. 실제 키를 이렇게 저장하면 사용자 데이터와 플레이북에 비밀정보가 남습니다.
변경 후
yaml
- name: start an instance
community.aws.ec2_instance:
name: credential-example
image_id: "{{ ami_id }}"
instance_type: "{{ instance_type }}"
vpc_subnet_id: "{{ subnet_id }}"
iam_instance_profile: "{{ instance_profile_name }}"
사용자 데이터에 키를 넣는 대신 인스턴스 프로파일을 연결합니다. 애플리케이션이 임시 자격 증명을 사용하고 필요한 권한만 갖는지 확인하세요. 이 변경만으로 이미 노출된 키가 폐기되지는 않습니다.