매일 쓰는 로그인, IAM 사용자와 Identity Center와 aws login
AWS 튜토리얼은 IAM 사용자의 액세스 키를 명령줄 설정에 붙여 넣으라고 하지만, 액세스 키는 지울 때까지 쓰이는 장기 자격 증명이다.
사람이 매일 쓰는 로그인은 Identity Center나 aws login처럼 시간이 정해진 임시 자격 증명을 받는 쪽으로 정하고, 무료 플랜 계정에서는 조직이 생기는 순간 플랜이 바뀐다는 점을 함께 따진다.
이 글의 목차명령줄도 서명한 요청을 보낸다8
AWS 튜토리얼을 따라가면 대개 같은 순서가 나온다.
루트로 콘솔에 들어가 IAM 사용자를 만들고, 그 사용자의 액세스 키를 발급받아 명령줄 도구 설정에 붙여 넣는다.
그런데 AWS의 IAM 모범 사례는 사람이 임시 자격 증명으로 AWS에 들어오게 하라고 권한다.
루트 사용자 글에서 본 대로 루트는 잠가 두었으니, 매일 콘솔과 명령줄에 들어갈 로그인은 따로 정해야 한다.
명령줄도 서명한 요청을 보낸다
콘솔에서 버튼을 누르든 AWS CLI(명령줄 도구)나 SDK(프로그램 안에서 AWS를 부르는 라이브러리)로 명령을 보내든, AWS에 닿는 것은 API 요청이다.
CLI와 SDK는 요청마다 자격 증명으로 계산한 서명을 붙인다.
자격 증명의 비밀 값은 요청에 실리지 않는다.
도구가 요청 내용과 비밀 값으로 서명을 계산해 붙이면, AWS가 같은 계산을 해서 맞춰 본다.
비밀 값을 손에 넣은 쪽은 누구든 그 신원으로 서명할 수 있다.
AWS는 서명으로 요청한 신원을 확인한 뒤, 그 신원에 붙은 정책이 이 작업을 허용하는지 본다.
정책은 어떤 작업을 허용하거나 거부할지 적은 문서다.
콘솔에서는 로그인만 하면 되니 자격 증명을 직접 다룰 일이 없다.
명령줄에서는 서명에 쓸 자격 증명을 도구가 갖고 있어야 해서, 튜토리얼이 액세스 키를 붙여 넣게 한다.
장기 자격 증명과 임시 자격 증명
루트 글에서 본 액세스 키는 IAM 사용자에게도 발급된다.
액세스 키 ID와 비밀 액세스 키 한 쌍이고, 만료 시각이 없어서 비활성화하거나 지우기 전까지 서명에 쓰인다.
이런 자격 증명을 장기 자격 증명이라고 한다.
임시 자격 증명은 처음부터 만료 시각을 달고 나온다.
그 시각이 지나면 같은 값으로 서명한 요청은 거부되니, 새어 나가도 쓰일 수 있는 기간이 그만큼 짧다.
둘은 액세스 키 ID의 앞 네 글자로도 구별된다.
AKIA로 시작하면 IAM 사용자나 루트의 장기 키이고, ASIA로 시작하면 임시 자격 증명의 키다.
신원은 세 갈래다
IAM 사용자는 한 계정 안에 만드는 신원이다.
콘솔 비밀번호와 액세스 키를 가질 수 있고, 둘 다 장기 자격 증명이다.
비밀번호도 만료 정책을 따로 켜지 않으면 바꿀 때까지 그대로 쓰인다.
콘솔 로그인 화면에서는 사용자 유형부터 고른다.
IAM 사용자는 그 화면에서 IAM 사용자를 고르거나, 계정 ID나 계정 별칭이 들어간 계정 전용 로그인 주소로 바로 들어간다.
IAM 역할은 맡는 동안만 쓰는 신원이다.
역할 자체에는 비밀번호도 액세스 키도 없다.
허락받은 사람이나 서비스가 역할을 맡을 때마다 만료 시각이 붙은 임시 자격 증명이 나오는데, 이것을 역할 세션이라고 한다.
IAM Identity Center는 사용자를 한곳에 두고 여러 계정에 들여보내는 서비스다.
사용자가 접근 포털이라는 로그인 페이지에서 계정과 권한 세트를 고르면, 그 계정의 역할 세션을 받는다.
권한 세트는 그 계정에서 할 수 있는 일을 정해 둔 묶음이다.
권한 세트를 계정에 할당하면 Identity Center가 그 계정에 IAM 역할을 만들어 두고, 사용자가 고를 때마다 그 역할의 세션을 내준다.
관리자 권한과 루트 전용 작업
IAM 사용자나 역할에 모든 작업을 허용하는 AdministratorAccess 정책을 붙이면 대부분의 일을 할 수 있다.
그래도 루트로 로그인해야만 하는 일은 하지 못한다.
조직에 묶이지 않은 계정에서 루트 이메일을 바꾸거나 계정을 해지하는 일이 그렇다.
그래서 평소에는 관리자 신원으로 일하고, 루트는 그런 일이 생길 때만 꺼낸다.
Identity Center를 켜면 조직이 생긴다
Identity Center로 사람을 AWS 계정에 들여보내려면 AWS Organizations의 조직이 있어야 한다.
조직에 묶이지 않은 독립 계정에서 AWS가 권하는 방식으로 켜면, 그 계정을 관리 계정으로 하는 조직이 새로 만들어진다.
로그인 화면만 바뀌는 것 같지만 계정의 구조가 바뀐다.
무료 플랜 글에서 본 대로 무료 플랜 계정은 조직이 생기는 순간 유료 플랜이 되고, 남은 크레딧이 즉시 만료된다.
Identity Center는 조직 인스턴스와 계정 인스턴스, 두 방식으로 켠다. 어느 계정에서 어느 방식으로 켜느냐에 따라 조직과 플랜이 달라지고, 사용자가 AWS 계정 콘솔에 들어갈 수 있는지도 달라진다.
- 조직새로 생김 · 이 계정이 관리 계정
- 플랜유료로 바뀜 · 크레딧 즉시 만료
- 사용자 접근권한 세트 → 계정의 역할 세션
- AWS 계정 콘솔들어감
- 조직생기지 않음
- 플랜무료 플랜 그대로
- 사용자 접근애플리케이션 로그인만
- AWS 계정 콘솔들어가지 못함
- 조직새로 생김 · 이 계정이 관리 계정
- 플랜유료 플랜 그대로
- 사용자 접근권한 세트 → 계정의 역할 세션
- AWS 계정 콘솔들어감
- 조직생기지 않음
- 플랜유료 플랜 그대로
- 사용자 접근애플리케이션 로그인만
- AWS 계정 콘솔들어가지 못함
- 조직이미 있음
- 플랜유료 플랜 그대로
- 사용자 접근권한 세트 → 계정의 역할 세션
- AWS 계정 콘솔들어감
조직 인스턴스만 권한 세트로 사용자를 AWS 계정 콘솔에 들여보낸다. 조직에 묶이지 않은 독립 계정에서 조직 인스턴스를 켜면 조직이 새로 생기고, 무료 플랜 계정은 이때 유료 플랜이 되어 남은 크레딧이 즉시 만료된다. 계정 인스턴스는 조직을 만들지 않지만 계정 콘솔에 들여보내지 못하고, 조직의 관리 계정에는 만들 수 없다.
조직이 새로 생기고, 사용자는 권한 세트로 이 계정의 콘솔에 들어간다. 대신 무료 플랜 계정은 조직이 생기는 순간 유료 플랜이 되고 남은 크레딧이 즉시 만료된다.
조직 관리 계정은 조직을 만들 때 이미 유료 플랜이 되었다고 본다. 구성원 계정에서 켜는 경우, 외부 ID 공급자를 연결하는 경우, 권한 세트 대신 IAM의 계정 접근 관리자로 역할을 주는 경우는 다루지 않는다.
키 없이 명령줄에 들어가는 길
CLI를 쓰려면 액세스 키가 꼭 있어야 한다고 여기기 쉽다.
지금은 키를 만들지 않고 임시 자격 증명을 받는 길이 둘 있다.
aws login은 콘솔 로그인으로 명령줄용 임시 자격 증명을 받는 명령이다.
루트, IAM 사용자, 외부 로그인으로 들어오는 IAM 페더레이션 사용자가 쓸 수 있고, AWS CLI 2.32.0 이상이 필요하다.
명령을 실행하면 브라우저가 열린다.
열려 있는 콘솔 세션을 고르거나 새로 로그인하면, 임시 자격 증명과 그것을 다시 받는 데 쓰는 갱신 토큰이 내 컴퓨터의 캐시에 저장된다.
장기 키는 어디에도 남지 않는다.
작업을 마치면 자격 증명이 저절로 만료되게 두거나, aws logout으로 캐시를 지운다.
IAM 사용자나 역할로 쓰려면 그 신원에 이 명령을 허용하는 권한이 있어야 하고, AWS는 이 용도로 SignInLocalDevelopmentAccess 정책을 마련해 두었다.
설정 순서는 AWS CLI의 로그인 문서에 있다.
권한 세트로 계정에 들어가는 Identity Center 사용자는 CLI의 SSO 설정을 쓴다.
aws configure sso로 설정한 뒤 브라우저에서 접근 포털에 로그인하고 계정과 권한 세트를 고르면, 그 역할 세션이 CLI로 내려온다.
키가 새고 기록이 흐려지는 자리
비밀 액세스 키는 만들 때 한 번만 내려받을 수 있어서, 발급한 자리에서 어딘가에 저장해 두어야 한다.
그렇게 옮겨 둔 키는 복사된 곳마다 그대로 쓰인다.
노트북의 자격 증명 파일, 셸 기록, AI 코딩 도구의 대화창, 저장소에 올린 커밋 어디에 남든, 키를 지우기 전까지 그 값으로 서명한 요청은 받아들여진다.
IAM 사용자 하나를 여러 사람이 나눠 쓰면 기록이 사람을 가리키지 못한다.
AWS 계정에서 일어난 작업을 남기는 CloudTrail에는 같은 사용자 이름만 쌓인다.
한 사람이 팀을 떠나는 날에는 남은 사람 모두가 쓰던 비밀번호와 키를 함께 바꿔야 한다.
새 로그인으로 바꾼 뒤에도 옛 액세스 키가 먼저 쓰일 수 있다.
명령에 프로필을 지정하지 않으면 CLI는 환경 변수에 든 키를 설정 파일보다 앞에 두고, 같은 프로필이라면 자격 증명 파일에 남은 키를 aws login보다 먼저 쓴다.
실무에서 로그인을 정하는 방식
실무에서는 한 사람에게 신원 하나를 주고 MFA를 건다.
IAM 사용자에게도 루트처럼 MFA 장치를 등록할 수 있고, AWS는 패스키와 보안 키를 권한다.
사람이 쓰는 장기 액세스 키는 만들지 않는 것을 기본으로 하고, 서버와 배포 작업의 권한은 역할로 준다.
여러 사람이 함께 쓰거나 계정이 여럿이거나 이미 유료 플랜이라면, 조직과 함께 Identity Center를 켜고 그 안에 관리 사용자를 만든다.
혼자 연습하는 무료 플랜 계정이라면 크레딧을 지키려고 조직을 만들지 않는다.
MFA를 건 IAM 사용자로 콘솔에 들어가고, 명령줄은 aws login으로 그 콘솔 로그인에서 임시 자격 증명을 받는다.
새 가입 방식으로 만든 계정에서는 IAM 사용자를 프로그램용으로만 만들 수 있어서, 콘솔에는 IAM 사용자로 로그인하지 못한다.
세 길이 남기는 자격 증명은 수명도 다르다.
액세스 키는 지울 때까지 쓰인다.
Identity Center의 역할 세션은 권한 세트에 정한 시간(기본 1시간, 최대 12시간)이 지나면 끝나고, CLI는 접근 포털 로그인이 살아 있는 동안(기본 8시간) 새 세션을 받아 온다.
aws login의 자격 증명은 15분짜리이고, 최대 12시간까지 새로 받는다.