I. 개요
이번 포스팅은 ‘Boto3가 AWS의 자격증명(Credentials)을 확인하는 순서’ 인 Credentials — Boto3 Docs 1.17.21 documentation > Configuring credentials
의 내용에 대해서, 테스트 환경을 구축하고 실제로 파이썬 코드를 통해서 각 단계의 권한을 얻어보고 확인해보는 과정 및 결과를 보여주고 있습니다.
II. 본문
1. Boto3 소개
가. 다양한 언어를 지원하는 AWS
AWS에서는 클라우드 인프라에 접근할수 있도록 다양한 프로그래밍 언어를 지원하고 있습니다.
AWS 개발자 센터 & AWS용 SDK 및 프로그래밍 도구 키트 – Amazon AWS
- CLI 쉘스크립트, 자바, 자바스크립트, 닷넷, php, 파이썬, 루비, Golang, C++
이 중에서, 파이썬 언어를 통해서 AWS의 클라우드 인프라에 접근하는 방법을 다룰 것입니다.
나. Boto3: Python용 AWS SDK
여기서 Boto3는 Python용 AWS SDK 를 의미합니다.
※ SDK 란?
소프트웨어 개발 키트(영어: Software Development Kit, SDK)는 일반적으로 소프트웨어 기술자가 사용하여 특정한 소프트웨어 꾸러미, 소프트웨어 프레임워크, 하드웨어 플랫폼, 컴퓨터 시스템, 게임기, 운영 체제 등을 위한 응용 프로그램 등을 만들 수 있게 해주는 개발 도구의 집합이다.
2. Boto3의 자격증명
가. Credentials과 Configuration
기본적으로 AWS 리소스에 접근하기 위해서는 필연적으로 AWS IAM(AWS Identity and Access Management) 으로부터 권한을 받아야합니다.
- IAM 서비스에는 Policy, Role, User, Group 등의 개념이 존재하지만, 여기서는 생략하겠습니다.
Boto3에는 자격증명(credentials) 과 비자격증명(non-credentials)의 두 가지 구성 데이터 유형이 있습니다.
자격증명: aws_access_key_id , aws_secret_access_key 및 aws_session_token 항목이 포함됩니다.
비자격증명: 사용할 리전 또는 Amazon S3에 사용할 주소 지정 스타일과 같은 항목이 포함됩니다.
→ 앞으로 비자격증명은 Configuration이라고 표현하겠습니다.
나. Boto3가 AWS의 자격증명(Credentials)을 확인하는 순서
Boto3는 자격증명을 얻을 때 여러 위치를 찾습니다. Boto3가 자격증명을 찾는 메커니즘은 가능한 위치 목록을 확인해보고 자격증명을 찾는 즉시 중지하는 것입니다. Boto3가 AWS의 자격증명을 확인하는 순서는 다음과 같습니다.
- boto3.client, resource, session 함수에 자격증명을 매개 변수로 직접 전달
- 환경 변수(Environment variables)
- 공유 자격증명 파일 [ ~/.aws/credentials ]
- AWS 구성 파일 [ ~/.aws/config ]
- AssumeRole(임시 자격증명) 호출 [ ~/.aws/config ]
- Boto2 구성 파일 [ /etc/boto.cfg 또는 ~/.boto ]
- IAM 역할이 구성된 Amazon EC2 인스턴스의 인스턴스 메타 데이터 서비스
이 아래의 내용은 각각의 경우에 대해서 직접 실행해보는 것을 설명하고 있습니다.
다. 테스트 환경
1. 테스트 환경 소개
우선 테스트 환경은 다음과 같습니다.
AWS 계정: 테스트용 개인 계정 [AWS 계정ID: 7792******85]
서울 리전: EC2 인스턴스(t2.nano, Amazon Linux 2 AMI (HVM), SSD Volume Type)
실행 위치: /home/ec2-user/boto3_demo_sample_code_ec2_instance_describe
2. 권한을 얻었는지 확인하는 코드
각각의 테스트 코드는 ‘권한을 얻는 코드’와 ‘ IAM 권한을 얻었는지 확인하는 코드’로 나뉩니다.
‘권한을 얻는 코드’는 이후의 예제에 따라 계속 바뀌지만, ‘ IAM 권한을 얻었는지 확인하는 코드’는 공통된 코드입니다.
이러한 공통 코드는 다음과 같습니다.
- 기능: EC2의 running 상태인 인스턴스에 대해서 NameTag, InstanceId 값을 출력합니다.
※ EC2 서비스의 describe_instances함수만 사용하는 예제 코드
※ 개인 테스트 계정의 서울리전(ap-northeast-2)에서 현재 활성화된 EC2 인스턴스 목록
그러므로 이 환경에서 제대로 권한을 얻었다면, 3개 인스턴스의 NameTag 및 InstanceId를 출력해야합니다.
라. 테스트 진행
테스트 진행은 순서대로, Boto3가 AWS의 자격증명을 확인하는 순서에 따라서, 각각에 대한 ‘1) 소개, 2) 사전 준비 사항, 3) 권한을 얻는 코드, 4) 실행 결과’ 로 이루어져 있습니다.
1. boto3.client, resource, session 함수에 자격증명을 매개 변수로 직접 전달
▣ 소개
제일 간단한 방법으로 각 메서드 에서 자격증명을 매개 변수로 직접 전달합니다.
단, 이 방식은 Client 등의 소스 코드에 Key값이 직접적으로 노출되므로 하드코딩 방식은 권장하지 않습니다.
- 추후 설명할 AssumeRole(임시 보안 자격증명)과 연계되는 경우를 권장합니다.
▣ 사전 준비 사항
이 방식은 직접적으로 함수에 전달할 접근키와 비밀키가 있어야 합니다.
※ 접근키&비밀키: AWS CLI, PowerShell용 도구, AWS SDK 또는 직접 AWS API 호출을 통해 AWS를 프로그래밍 방식으로 호출할 때 필요한 자격증명 정보
현재 필요한 권한은 EC2 서비스의 describe_instances함수만이므로 다음의 권한을 가진 사용자를 생성해서 접근키&비밀키를 얻었습니다.
※ 참고. 현재 보여지는 키는 테스트 계정에서 임시로 생성한 User에 대해서, EC2 서비스의 describe_instances 권한만 부여된 키이며, 현재는 삭제된 키입니다.
▣ 권한 얻는 코드
1-1) Client 함수에 전달 Resource 함수에 전달
1-2) Resource 함수에 전달
※ 리소스 함수는 특정 리소스 객체에 대한 접근방법이라서 별도의 코드를 이용하였습니다.
1-3) Session 함수에 전달 [이후 ‘ec2’ 서비스의 client 또는 resource 호출]
※ 생략된 내용은 client, resource 각각의 권한 확인용 코드가 있습니다.
▣ 실행 결과
2. 환경 변수(Environment variables)
▣ 소개
Boto3는 다음의 환경 변수에서 자격증명을 확인합니다.
- AWS_ACCESS_KEY_ID : AWS 계정의 액세스 키입니다.
- AWS_SECRET_ACCESS_KEY : AWS 계정의 비밀 키입니다.
- AWS_SESSION_TOKEN : AWS 계정의 세션 키입니다. 임시 자격증명을 사용하는 경우에만 필요합니다. AWS_SECURITY_TOKEN의 환경 변수도 사용할 수 있지만 이전 버전과의 호환성을 위해 지원됩니다. AWS_SECURITY_TOKEN 은 Python 외에 여러 AWS SDK에서 지원됩니다.
▣ 사전 준비 사항
Linux 환경 기준, 『export <변수명>=<변수값>』 명령어로 환경변수를 설정한 뒤
『env』 내지 『export』 명령어로 환경변수 목록을 확인할 수 있습니다.
export AWS_ACCESS_KEY_ID=YOUR_ACCESS_KEY
export AWS_SECRET_ACCESS_KEY=YOUR_SECRET_KEY
export AWS_DEFAULT_REGION=AWS_REGION_INFO
- 환경구성 및 확인
※ 방금전에 설정한, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_DEFAULT_REGION 값이 OS의 환경변수로 설정되어 있는것을 확인할 수 있습니다.
▣ 권한 얻는 코드
이렇게 되어 있으면, Client 등의 소스 코드에 Key값이 직접적으로 노출되지 않아도 됩니다.
※ 이번을 포함해서 이후 예제는 소스코드에 Key값이 직접적으로 노출되지 않습니다.
▣ 실행 결과
- 환경 변수 해제
다음 단계를 확인하기 위해서 Linux 환경 기준, 『unset <변수명>』 명령어로 환경변수를 해제합니다.
unset AWS_ACCESS_KEY_ID
unset AWS_SECRET_ACCESS_KEY
unset AWS_DEFAULT_REGION
3. 공유 자격증명 파일 [ ~/.aws/credentials ]
▣ 소개
그 다음으로 확인하는 값은 공유 자격증명(credentials) 파일입니다.
- credentials 파일의 기본 위치는 ~/.aws/credentials 입니다.
- 홈 디렉토리 위치는 운영 체제에 따라 다르지만 Windows 에서는 %UserProfile% 환경 변수를 사용하고 Unix 기반 시스템에서는 $HOME 또는 ~(물결표) 를 사용하는 것으로 참조됩니다.
- AWS_SHARED_CREDENTIALS_FILE 환경 변수를 설정하여 credentials 파일의 위치를 변경할 수 있습니다.
- 이 파일은 프로필에 해당하는 섹션 이름이 있는 INI 형식 파일입니다.
- 각 섹션에서 위에 표시된 세 가지 구성 변수인 aws_access_key_id, aws_secret_access_key, aws_session_token만 지정할 수 있습니다.
- 즉, credentials 파일은 ‘자격증명’과 관련된 정보만 저장할 수 있습니다.
※ INI 형식 파일이란?
INI(Initialization) 파일 포맷은 설정 파일에 대한 de facto 표준이다. INI 파일은 단순 구조의 텍스트 파일로 이루어져 있다. 출처: INI 파일 – 위키백과, 우리 모두의 백과사전
+ α. 모두 ASCII 문자만 포함하는 일반 텍스트 파일입니다. [한글 입력시 에러]
+ β. 하나 이상의 공백으로 들여 쓰기하여 부분 집합을 그룹과 연결할 수 있습니다.
+ γ. 예시를 든다면 다음의 형식입니다.
[section-name]
setting-name1 = value1 ; Semicolon (;) means comment.
setting-name2 =
setting-name3 = value3 ; The value of 3,4 is contained in setting-name2.
setting-name4 = value4
credentials 파일 형식 예제
[default] ; default Profile section information
aws_access_key_id = YOUR_ACCESS_KEY1
aws_secret_access_key = YOUR_SECRET_KEY1
aws_session_token = YOUR_SESSION_TOKEN1
[dev] ; dev Profile section information
aws_access_key_id = YOUR_ACCESS_KEY2
aws_secret_access_key = YOUR_SECRET_KEY2
[prod] ; prod Profile section information
aws_access_key_id = YOUR_ACCESS_KEY3
aws_secret_access_key = YOUR_SECRET_KEY3
※ aws_session_token 값은 필수 입력값은 아니며, 생략이 가능합니다.
※ Session을 생성할 때 AWS_PROFILE 환경 변수 또는 profile_name 매개변수 값을 통해서 프로필 이름을 지정할 수 있습니다 .
▣ 사전 준비 사항
credentials 파일 설정 방식
1) 『aws configure [–profile profile-name]』 명령어를 통해서 지정 ← ‘-‘ 2개
■ AWS CLI가 있는 경우 사용 가능
2) mkdir, vi, nano 등의 명령어로 ~/.aws/credentials, config 파일을 직접 수정
1) 『aws configure [—profile profile-name]』 명령어를 이용한 방식 ← ‘-‘ 2개
※ [profile_name] 값이 없으면 ‘default’ 값으로 들어갑니다.
- 환경구성 확인
▣ 권한 얻는 코드
3-1) 디폴트 프로필 이용
3-2) test-profile2 프로필 이용
▣ 실행 결과
4. AWS 구성 파일 [ ~/.aws/config ]
▣ 소개
그 다음으로는 구성(config) 파일을 확인합니다.
- config 파일의 기본 위치는 ~/.aws/config 입니다.
- AWS_CONFIG_FILE 환경 변수를 설정하여 config 파일의 위치를 변경 할 수 있습니다.
- INI 형식 파일입니다.
※ Config 값을 확인하는 순서
사실 ~/.aws/config 값을 바로 확인하지는 않습니다. 이번 주제인 ‘Boto3가 AWS의 자격증명(Credentials)을 확인하는 순서’처럼 Config 값 역시 실질적으로는
1) boto3.client, resource, session 권한을 얻을 때 botocore.config로 별도로 생성한 Config값을 직접 넘겨주면 이 값을 사용하고,
2) AWS_PROFILE, AWS_RETRY_MODE 와 같은 환경변수 값이 있는지 확인하며,
3) 마지막으로 ~/.aws/config 파일의 값을 확인하는 방식으로
Config 값을 읽어옵니다.
config 파일 형식 예제
[default] ; default Profile section information
aws_access_key_id = YOUR_ACCESS_KEY1
aws_secret_access_key = YOUR_SECRET_KEY1
[profile dev] ; dev Profile section information
aws_access_key_id = YOUR_ACCESS_KEY2
aws_secret_access_key = YOUR_SECRET_KEY2
[profile prod] ; prod Profile section information
aws_access_key_id = YOUR_ACCESS_KEY3
aws_secret_access_key = YOUR_SECRET_KEY3
※ default 프로필을 제외한, 프로필 섹션의 형식은 [profile profile-name] 입니다.
※ config 파일은 앞선 credentials 파일의 aws_access_key_id, aws_secret_access_key, aws_session_token 구성변수를 포함해서, region, output, role_arn, source_profile, credential_source, external_id 등의 다양한 구성변수도 설정할 수 있습니다.
▣ 사전 준비 사항
Config 파일 설정 [vi명령어를 통해서 아래의 내용을 추가]
[profile test-profile3]
output = json
region = ap-northeast-2
aws_access_key_id = YOUR_ACCESS_KEY
aws_secret_access_key = YOUR_SECRET_KEY
- 환경구성 확인
※ 이번 예시는 credentials 파일이 꼭 있어야함을 의미하는 것이 아니라, config 파일만으로도 권한을 얻어올 수 있음을 설명하는 예시라서 장기자격증명 값을 config 파일에 넣었지만, 장기자격증명 값은 기본적으로 credentials 파일에만 넣는 것을 권장합니다.
▣ 권한 얻는 코드
▣ 실행 결과
5. AssumeRole(임시 자격증명) 호출 [ ~/.aws/config ]
AssumeRole은 『AWS 리소스에 대한 작업권한을 가진, 단기적으로 발급된 임시 자격증명』입니다.
- 본래 AssumeRole은 다섯 번째로 IAM 권한을 확인하지만 구성이 상대적으로 복잡한 관계로 맨 마지막에 설명하겠습니다.
6. Boto2 구성 파일 ( /etc/boto.cfg 또는 ~/.boto )
▣ 소개
AssumeRole 정보도 없으면 Boto2 구성 파일에서 자격증명을 읽으려고 시도합니다. 먼저 설정된 경우 BOTO_CONFIG 가 가리키는 파일을 확인하고, 그렇지 않으면 /etc/boto.cfg 및 ~/.boto를 확인합니다.
- Boto 구성파일 의 [Credentials] 섹션만 사용됩니다.
- 예전에 사용되었던 방식으로 존재는 하지만 실질적으로는 거의 안 쓰이는 방식입니다.
▣ 사전 준비 사항
boto.cfg 파일 설정
[Credentials]
aws_access_key_id = YOUR_ACCESS_KEY
aws_secret_access_key = YOUR_SECRET_KEY
- 환경구성 확인
▣ 권한 얻는 코드
▣ 실행 결과
7. IAM 역할이 구성된 Amazon EC2 인스턴스의 인스턴스 메타 데이터 서비스
▣ 소개
앞서서 적합한 자격 증명을 하나도 찾지 못했고, 해당 파이썬 프로그램이 Amazon EC2에서 실행중이면 Boto3는 인스턴스 메타 데이터 서비스에서 자격 증명을 읽으려고 시도합니다.
▣ 사전 준비 사항
해당 파이썬 프로그램이 Amazon EC2 인스턴스에는 접근할 IAM Role이 지정되어 있어야합니다.
Step1. ‘demo-ec2-role’ 역할 생성
※ EC2 서비스의 describe_instances함수 권한만 존재
Step2. EC2 인스턴스 환경에서, EC2 인스턴스에 권한이 있는 IAM Role 부여
- 테스트 환경 EC2 인스턴스 우클릭 > 보안 > IAM 역할 수정
- 방금 생성한 ‘demo-ec2-role’ 역할 선택 후 저장
- Role이 있는지 인스턴스 메타데이터를 확인하는 명령어: 『curl http://169.254.169.254/latest/meta-data/iam/info』
※ 인스턴스 메타데이터란?
인스턴스 메타데이터는 실행 중인 인스턴스를 구성 또는 관리하는 데 사용될 수 있는 인스턴스 관련 데이터입니다. 인스턴스 메타데이터는 예를 들어 호스트 이름, 이벤트 및 보안 그룹과 같은 범주로 분류됩니다.
IP 주소 ‘169.254.169.254'는 인스턴스의 정보를 확인할 수 있는 링크-로컬 주소입니다. 이러한 동일한 IP 값을 어느 AWS계정, 리전, 인스턴스에서 수행해도 동일한 결과를 얻을 수 있으며, 인스턴스에서만 유효하게 작동합니다.
해당 명령어의 사용 방식은 『curl http://169.254.169.254/latest/meta-data/instancedata-data-categories』 입니다.
AWS aws-documentation Amazon EC2 Linux 인스턴스용 사용 설명서 > iam/info 외의 인스턴스 메타데이터 카테고리 확인
▣ 권한 얻는 코드
7-1) 별도 설정 없이 기본 Role만 붙였을 때
7-2) Role을 config 파일에 별도의 [profile 세션]을 붙여서 관리할 때
또한 Role을 config 파일에 별도의 [profile 세션]을 붙여서 관리할 수도 있습니다.
Config 파일 설정 [vi명령어를 통해서 아래의 내용을 추가]
[profile test-profile4]
output = json
region = ap-northeast-2
role_arn = YOUR_ROLE_ARN
credential_source = Ec2InstanceMetadata
- 환경구성 확인
+ 단, 이 경우는 Ec2InstanceMetadata를 사용하는 것 자체가 마지막으로 설명할 AssumeRole를 사용하는 것이므로, ‘demo-ec2-role’에 STS 서비스의 AssumeRole 권한이 추가로 더 필요합니다.
- 이때의 코드
▣ 실행 결과
8. AssumeRole(임시 자격증명) 호출 [ ~/.aws/config ]
▣ 소개
AssumeRole은 『AWS 리소스에 대한 작업권한을 가진, 단기적으로 발급된 임시 자격증명』입니다.
- AWS Security Token Service(AWS STS) 서비스를 통해 발급받습니다.
- 액세스 키 ID, 보안 액세스 키 및 보안 토큰으로 구성됩니다.
- 파일상으로 저장되지 않고 메모리에 일시적으로 생성됩니다.
- 임시 자격 증명은 지정된 간격 후에 만료됩니다. 자격 증명이 만료된 후에는 그 자격 증명을 사용한 어떤 요청도 실패할 것이므로 일련의 새로운 자격 증명을 얻어야 합니다. [디폴트 시간은 1시간. 최소 15분부터 최대 12시간까지 별도 지정가능]
※ AWS STS의 API 작업의 종류
임시 보안 자격 증명을 반환하는 AWS STS의 API 작업에는 아래의 5가지 작업이 있습니다.
1) AssumeRole—사용자 지정 자격 증명 브로커를 통한 교차 계정 위임 및 연동
2) AssumeRoleWithWebIdentity—웹 기반 자격 증명 공급자를 통한 연동
3) AssumeRoleWithSAML—SAML 2.0과 호환되는 엔터프라이즈 자격 증명 공급자를 통한 연동
4) GetFederationToken—사용자 지정 자격 증명 브로커를 통한 연동
5) GetSessionToken—신뢰할 수 없는 환경에 있는 사용자를 위한 임시 자격 증명
본 포스팅에서는 ‘1) AssumeRole—사용자 지정 자격 증명 브로커를 통한 교차 계정 위임 및 연동’ 에 대해서만 다루겠습니다.
AssumeRole 사용하는 방법 2가지
1) ~/.aws/config 파일의 프로필 세션 정보에 필요한 role_arn, source_profile 값을 입력해서 처리 : Boto3가 사용자를 대신하여 AWS STS에 해당하는 AssumeRole 호출을 자동으로 수행합니다. 필요에 따라 자격증명을 새로 고칠뿐만 아니라 메모리 내 캐싱을 처리합니다.
2) Python 코드 내에서 직접 AWS STS – AssumeRole() 함수 호출
: 현재 연결된 session 계정의 Role 중에서 RoleArn을 직접 입력해서 처리합니다.
AssumeRole을 사용하기 위한 조건 2가지
1) 초기 연결에서 STS Client 서비스의 AssumeRole 함수에 대한 IAM 권한이 있어야 합니다.
2) AssumeRole로 접근할 IAM Role에서 현재 계정과의 신뢰관계가 설정되어 있어야 합니다.
▣ 사전 준비 사항
Step1. ‘demo-sts-role’ 역할 생성
STS Client 서비스의 AssumeRole 함수 권한만 가진 Role 생성
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: “sts:AssumeRole”,
“Resource”: “*”
}
]
}
※ 참고. Boto3만으로 IAM AssumeRole을 생성하고 싶으면, ‘sts:AssumeRole’ 권한만으로도 충분하지만, AWS CLI를 사용해서 AssumeRole을 생성하고 싶으면, 해당 권한만으로는 부족하고, ‘iam:ListRoles’ 권한도 필요합니다.
- “Action”: 의 내용을 [ “iam:ListRoles”, “sts:AssumeRole” ] 으로 변경
Step2. EC2 인스턴스 환경에서, EC2 인스턴스에 권한이 있는 IAM Role 부여
- 방금 생성한 ‘demo-sts-role’ 역할 선택 후 저장
Step3. ‘demo-ec2-role’ 역할에 신뢰관계 부여
AssumeRole로 접근할 IAM Role에서 현재 계정과의 신뢰관계를 설정합니다.
- 다음의 내용 추가
,{
“Effect”: “Allow”,
“Principal”: {
“AWS”: “arn:aws:iam::YOUR_AWS_ACCOUNT_ID:root”
},
“Action”: “sts:AssumeRole”
}
Step4. Config 파일 설정
- ~/.aws/config 파일의 프로필 세션 정보에 필요한 role_arn, source_profile 값을 입력
source_profile: 초기 AssumeRole 호출에 사용할 자격증명이 포함된 프로필 이름입니다.
※ credential_source 및 source_profile 설정은 상호 배타적입니다. [하나의 섹션 안에 둘 다 존재할 수 없습니다]
vi명령어를 통해서 아래의 내용을 추가
[profile test-profile5]
output = json
region = ap-northeast-2
role_arn = YOUR_ROLE_ARN1 ; [ARN of Role with AssumeRole authority of STS service]
credential_source = Ec2InstanceMetadata
[profile test-profile6]
output = json
region = ap-northeast-2
role_arn = YOUR_ROLE_ARN2 ; [ARN of the role you want to create with AssumeRole]
source_profile = test-profile5
role_session_name = NDS-session-1st
※ 의미 설명: test-profile6에는 지정한 role_arn을 AssumeRole 로 접근하되, STS AssumeRole 권한은 source_profile에서 지정한 test-profile5 로부터 얻는다는 의미입니다.
- 환경구성 확인
▣ 권한 얻는 코드
5-1) ~/.aws/config 파일의 프로필 세션 정보에 필요한 role_arn, source_profile 값을 입력해서 처리
5-2) Python 코드 내에서 직접 AWS STS – AssumeRole() 함수 호출
실질적으로는
1) STS 서비스의 assume_role 함수를 실행할 권한을 얻고
2) 이를 바탕으로 assume_role을 생성하고
3) 얻은 반환값의 임시 credentials 값을 통해서 별도 연결을 하는
3가지 과정으로 이루어집니다.
▣ 실행 결과
III. 마무리
복습 차원에서 ‘Boto3가 AWS의 자격증명(Credentials)을 확인하는 순서’를 다시 보겠습니다.
- boto3.client, resource, session 함수에 자격증명을 매개 변수로 직접 전달
- 환경 변수(Environment variables)
- 공유 자격증명 파일 [ ~/.aws/credentials ]
- AWS 구성 파일 [ ~/.aws/config ]
- AssumeRole(임시 자격증명) 호출 [ ~/.aws/config ]
- Boto2 구성 파일 [ /etc/boto.cfg 또는 ~/.boto ]
- IAM 역할이 구성된 Amazon EC2 인스턴스의 인스턴스 메타 데이터 서비스
이제 기본적으로 Boto3에서 내가 원하는 자격증명을 읽어오지 못한다면 다음의 순서대로 확인해봐야합니다.
1. 보통 boto3.client, resource, session 함수에 자격증명을 매개 변수로 직접 전달하는 경우는 최우선순위 값을 갖기 때문에 만약 여기서 에러가 난다면,
→ 내가 사용한 키값 자체가 존재는 하는지와 [복사 붙여넣기를 일부 안했다든지, 아니면 접근키가 비활성화 혹은 삭제되었는지]
→ 키와 연결된 정책, 역할 등의 IAM 권한이, 내가 호출하는 서비스 및 함수들의 권한을 포함하고 있는지를 확인합니다.
2. credentials, config 파일[profile_name 값을 통해 값을 넘겨줌]을 사용하는데 에러가 난다면,
→ 혹시 AWS_ACCESS_KEY_ID 와 같은 자격증명 값이 환경변수로 등록되었는지 확인합니다.
→ [선택] 『env』 내지 『export』 명령어로 환경변수 목록을 확인합니다.
→ 『unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN AWS_DEFAULT_REGION』
명령어로 환경변수를 해제합니다.
3. AssumeRole을 사용하는데 에러가 난다면,
→ 1) 초기 연결에서 STS Client 서비스의 AssumeRole 함수에 대한 IAM 권한이 있는지,
2) AssumeRole로 접근할 IAM Role에서 현재 계정과의 신뢰관계가 설정되어 있는지 확인합니다.
4. Amazon EC2 인스턴스에 직접 IAM Role를 붙였는데 에러가 난다면,
- 해당 방법의 우선순위가 최하위라는 점을 알고 있는 상황에서, 앞 단계들에서 자격증명 검색 우선순위를 가로막는 것은 없는지 확인합니다.
사실, Boto3의 3, 4, 5, 7번의 방법은 기본적으로 credentials, config 파일의 ‘profile_name’ 값으로 개별 세션 연결을 구성할 수 있습니다.
이 경우는 자격증명 검색 우선순위와 상관없이 최우선적으로 반영하므로 ‘profile_name’ 값을 통한 세션 연결을 하는 것을 권장드립니다.
IV. 참고 자료
AWS aws-documentation AWS Command Line Interface 사용 설명서 > AWS CLI 구성 > 환경 변수: 환경 변수를 사용하여 AWS CLI 구성
Boto3 Docs 1.17.19 documentation > Docs Developer guide > Configuration
Boto3 Docs 1.17.19 documentation > Docs Developer guide > Credentials
AWS Documentation AWS Security Token Service API Reference > Actions > AssumeRole
이 글의 저자는 SA 김제헌입니다. 2021년 03월 12일에 공개하고 2021년 03월 15일에 마지막으로 수정했습니다.
문의 사항이 있으시면, NDS Sales팀으로 연락 주시길 바랍니다. cloud.sales@nongshim.co.kr