OpenID Connect 페더레이션을 위한 역할 생성(콘솔)
AWS 계정에 AWS Identity and Access Management 사용자를 생성하는 대신 OpenID Connect(OIDC) 페더레이션형 ID 제공업체를 사용할 수 있습니다. 자격 증명 공급자(IdP)를 사용하면 AWS 외부의 사용자 자격 증명을 관리할 수 있고 이 외부 사용자 자격 증명에 계정의 AWS 리소스에 대한 사용 권한을 부여할 수 있습니다. 페더레이션과 IdP에 대한 자세한 내용을 알아보려면 자격 증명 공급자 및 페더레이션 섹션을 참조하세요.
OIDC 역할 생성을 위한 사전 조건
OIDC 페더레이션을 위한 역할을 만들기 전에 먼저 다음 사전 조건 단계를 완료해야 합니다.
OIDC 페더레이션을 위한 역할 생성 준비
-
페더레이션 OIDC ID를 제공하는 하나 이상의 서비스로 가입합니다. AWS 리소스로 액세스가 필요한 앱을 생성하면 공급자 정보로 앱도 구성합니다. 이렇게 하면 제공업체는 앱의 고유한 애플리케이션 및 시청자 ID를 제공합니다. (공급자마다 이 프로세스에 대해 다른 용어를 사용합니다. 이 가이드에서는 공급자에 앱을 식별하는 프로세스를 구성이라는 용어로 설명합니다.) 각 공급자로 여러 개의 앱을 구성하거나 단일 앱을 통해 다양한 공급자를 구성할 수 있습니다. 다음과 같이 ID 제공자에 대한 정보를 봅니다.
-
Facebook 개발자 사이트의 앱 또는 웹 사이트에 Facebook 로그인 추가하기
-
Google 개발자 사이트의 OAuth 2.0을 사용한 로그인(OpenID Connect)
-
IdP로부터 필요한 정보를 받은 후 IAM에서 IdP를 생성합니다. 자세한 내용은 IAM에서 OIDC(OpenID Connect) ID 공급자 생성 단원을 참조하세요.
중요
Google, Facebook 또는 Amazon Cognito의 OIDC IdP를 사용하는 경우 AWS Management Console에서 IAM IdP를 별도로 생성하지 마세요. 이러한 OIDC ID 제공자는 이미 AWS에 내장되어 있고 용도에 맞게 사용할 수 있습니다. 이 단계를 건너뛰고 다음 단계에서 IdP를 사용하여 새 역할을 생성합니다.
-
IdP를 통해 인증된 사용자가 맡을 역할에 대한 정책을 준비합니다. 다른 어떤 역할과 마찬가지로 모바일 앱을 위한 역할에는 2개의 정책이 포함됩니다. 하나는 역할을 위임할 사용자를 지정하는 신뢰 정책입니다. 다른 하나는 모바일 앱의 액세스가 허용 또는 거부되는 AWS 작업 및 리소스를 지정하는 권한 정책입니다.
웹 IdP의 경우, Amazon Cognito
를 사용하여 보안 인증을 관리하는 것이 좋습니다. 이 경우 이 예제와 비슷한 신뢰 정책을 사용합니다. { "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Principal": {"Federated": "cognito-identity.amazonaws.com"}, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": {"cognito-identity.amazonaws.com:aud": "
us-east-2:12345678-abcd-abcd-abcd-123456
"}, "ForAnyValue:StringLike": {"cognito-identity.amazonaws.com:amr": "unauthenticated"} } } }us-east-2:12345678-abcd-abcd-abcd-123456
을 Amazon Cognito에서 할당하는 아이덴티티 풀 ID로 바꿉니다.신뢰 정책을 생성할 때 OIDC IdP를 수동으로 구성하려면 자체 앱만이 이 역할을 수임한다고 보장하는 세 가지 값을 사용해야 합니다.
-
Action
요소에 대해서는sts:AssumeRoleWithWebIdentity
작업을 사용하세요. -
Principal
요소에 대해서는{"Federated":
문자열을 사용하세요.providerUrl/providerArn
}-
일부 범용 OIDC IdP의 경우,
이 URL입니다. 다음 예제는 일부 범용 IdP에 대해 보안 주체를 지정하는 방법을 포함합니다.providerUrl
"Principal":{"Federated":"cognito-identity.amazonaws.com"}
"Principal":{"Federated":"www.amazon.com"}
"Principal":{"Federated":"graph.facebook.com"}
"Principal":{"Federated":"accounts.google.com"}
-
다른 OIDC 제공업체의 경우, 다음 예제와 같이 단계 2에서 생성한 OIDC IdP의 Amazon 리소스 이름(ARN)을 사용합니다.
"Principal":{"Federated":"arn:aws:iam::123456789012:oidc-provider/server.example.com"}
-
-
권한을 제한하려면
Condition
요소에StringEquals
조건을 사용합니다. 자격 증명 풀 ID(Amazon Cognito용) 또는 앱 ID(다른 공급자용)를 테스트합니다. 아이덴티티 풀 ID는 IdP를 통해 앱을 구성할 때 얻은 앱 ID와 일치해야 합니다. 이러한 ID 간의 일치는 요청이 앱에서 오는지 확인합니다.참고
Amazon Cognito 자격 증명 풀의 IAM 역할은 서비스 보안 주체
cognito-identity.amazonaws.com
의 역할 수임을 신뢰합니다. 이 유형의 역할에는 역할을 수임할 수 있는 보안 주체를 제한하기 위한 조건 키가 하나 이상 포함되어야 합니다.크로스 계정 IAM 역할을 수임하는 Amazon Cognito 자격 증명 풀에는 추가 고려 사항이 적용됩니다. 이러한 역할의 신뢰 정책은
cognito-identity.amazonaws.com
서비스 보안 주체를 수락해야 하며 의도한 자격 증명 풀의 사용자로 역할 수임을 제한하는aud
조건 키를 포함해야 합니다. 이 조건 없이 Amazon Cognito 자격 증명 풀을 신뢰하는 정책은 의도하지 않은 자격 증명 풀의 사용자가 역할을 맡을 수 있는 위험을 야기합니다. 자세한 내용은 Amazon Cognito 개발자 안내서의 Trust policies for IAM roles in Basic (Classic) authentication을 참조하세요.사용하는 IdP에 따라 다음 예제 중 하나와 비슷한 조건 요소를 생성합니다.
"Condition": {"StringEquals": {"
cognito-identity.amazonaws.com:aud
": "us-east:12345678-ffff-ffff-ffff-123456"}}"Condition": {"StringEquals": {"
www.amazon.com:app_id
": "amzn1.application-oa2-123456"}}"Condition": {"StringEquals": {"
graph.facebook.com:app_id
": "111222333444555"}}"Condition": {"StringEquals": {"
accounts.google.com:aud
": "66677788899900pro0"}}OIDC 공급자의 경우 다음 예시와 같이
aud
컨텍스트 키로 OIDC IdP의 정규화된 URL을 사용합니다."Condition": {"StringEquals": {"
server.example.com:aud
": "appid_from_oidc_idp"}}
참고
역할의 신뢰 정책에서 보안 주체에 대한 값은 하나의 IdP에 고유합니다. OIDC 역할은 오직 하나의 보안 주체만을 지정할 수 있습니다. 따라서 모바일 앱이 사용자에게 1개 이상의 IdP에서 로그인할 수 있게 허용한다면 지원하고자 하는 각각의 IdP에 대한 개별 역할을 생성합니다. 각 IdP에 대한 개별 신뢰 정책을 생성합니다.
사용자가 모바일 앱을 사용하여 Login with Amazon에서 로그인하는 경우 다음 예제 신뢰 정책이 적용됩니다. 예제에서
amzn1.application-oa2-123456
은 Login with Amazon을 이용해 앱을 구성할 때 Amazon에서 할당하는 앱 ID를 나타냅니다.{ "Version": "2012-10-17", "Statement": [{ "Sid": "RoleForLoginWithAmazon", "Effect": "Allow", "Principal": {"Federated": "www.amazon.com"}, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": {"StringEquals": {"www.amazon.com:app_id": "
amzn1.application-oa2-123456
"}} }] }사용자가 모바일 앱을 사용하여 Facebook에서 로그인하는 경우 다음 예제 신뢰 정책이 적용됩니다. 이 예제에서
111222333444555
는 Facebook에서 할당하는 앱 ID를 나타냅니다.{ "Version": "2012-10-17", "Statement": [{ "Sid": "RoleForFacebook", "Effect": "Allow", "Principal": {"Federated": "graph.facebook.com"}, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": {"StringEquals": {"graph.facebook.com:app_id": "
111222333444555
"}} }] }사용자가 모바일 앱을 사용하여 Google에서 로그인하는 경우 다음 예제 신뢰 정책이 적용됩니다. 이 예제에서
666777888999000
은 Google에서 할당하는 앱 ID를 나타냅니다.{ "Version": "2012-10-17", "Statement": [{ "Sid": "RoleForGoogle", "Effect": "Allow", "Principal": {"Federated": "accounts.google.com"}, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": {"StringEquals": {"accounts.google.com:aud": "
666777888999000
"}} }] }사용자가 모바일 앱을 사용하여 Amazon Cognito에서 로그인하는 경우 다음 예제 신뢰 정책이 적용됩니다. 이 예제에서
us-east:12345678-ffff-ffff-ffff-123456
은 Amazon Cognito에서 할당하는 아이덴티티 풀 ID를 나타냅니다.{ "Version": "2012-10-17", "Statement": [{ "Sid": "RoleForCognito", "Effect": "Allow", "Principal": {"Federated": "cognito-identity.amazonaws.com"}, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": {"StringEquals": {"cognito-identity.amazonaws.com:aud": "
us-east:12345678-ffff-ffff-ffff-123456
"}} }] } -
OIDC 역할 생성
사전 요구 사항을 완료한 후에는 IAM에서 역할을 생성할 수 있습니다. 다음 절차는 AWS Management Console에서 OIDC 페더레이션 역할을 생성하는 방법을 설명합니다. AWS CLI 또는 AWS API에 역할을 만들려면 타사 ID 제공업체의 역할 생성(페더레이션)의 절차 섹션을 참조하세요.
중요
Amazon Cognito를 사용하는 경우 Amazon Cognito 콘솔을 사용하여 역할을 설정합니다. 그 외에는 IAM 콘솔을 사용하여 OIDC 페더레이션의 역할을 생성합니다.
OIDC 페더레이션을 위한 IAM 역할 생성
AWS Management Console에 로그인하여 https://console.aws.amazon.com/iam/
에서 IAM 콘솔을 엽니다. -
탐색 창에서 역할을 선택한 후 역할 생성을 선택합니다.
-
신뢰할 수 있는 엔터티 유형으로 웹 자격 증명을 선택하고 다음을 선택합니다.
-
자격 증명 공급자(Identity provider)에서 역할의 IdP를 선택합니다.
-
개별 웹 IdP에 대한 역할을 생성하는 경우, Login with Amazon, Facebook 또는 Google을 선택합니다.
참고
지원할 각 IdP에 대해 별도의 역할을 생성해야 합니다.
-
Amazon Cognito의 고급 시나리오 역할을 생성하려는 경우 Amazon Cognito를 선택합니다.
참고
고급 시나리오에서 작업하는 경우에만 Amazon Cognito에서 사용할 역할을 수동으로 생성해야 합니다. 그렇지 않은 경우 Amazon Cognito가 역할을 대신 생성할 수 있습니다. 자세한 내용은 Amazon Cognito 개발자 안내서의 자격 증명 풀(페더레이션 자격 증명) 외부 자격 증명 공급자를 참조하세요.
-
GitHub 작업을 위한 역할을 만들려는 경우 먼저 GitHub OIDC 공급자를 IAM에 추가해야 합니다. IAM에 GitHub OIDC 공급자를 추가한 후 token.actions.githubusercontent.com을 선택합니다.
참고
GitHub의 OIDC 제공자를 페더레이션형 ID로 신뢰하도록 AWS를 구성하는 방법에 대한 자세한 내용은 GitHub Docs - Configuring OpenID Connect in Amazon Web Services
를 참조하세요. GitHub용 IAM IdP와 관련된 역할에 대한 액세스를 제한하는 모범 사례에 대한 자세한 내용은 이 페이지의 GitHub OIDC ID 제공자의 역할 구성을 참조하세요. -
HashiCorp Cloud Platform(HCP) Terraform에 대한 역할을 생성하려면 먼저 Terraform OIDC 제공자를 IAM에 추가해야 합니다. IAM에 Terraform OIDC 제공자를 추가한 후 app.terraform.io를 선택합니다.
중요
HashiCorp Cloud Platform(HCP) Terraform OIDC 제공자에 대한 IAM 역할은 역할 신뢰 정책에서 IAM 조건 키
app.terraform.io:sub
를 평가해야 합니다. 이 조건 키는 역할을 수임할 수 있는 HCP Terraform 조직, 프로젝트, 워크스페이스 또는 실행 단계를 제한합니다. 이 조건 키가 없으면 신뢰 정책은 조직 외부의 ID로 역할 및 AWS 리소스에 대한 액세스 권한을 부여합니다. 이는 최소 권한 원칙에 부합하지 않습니다.AWS 계정의 HCP Terraform OIDC 제공자와 연결된 역할에 대한 역할 신뢰 정책을 설정하거나 수정하지만 IAM 조건 키
app.terraform.io:sub
를 평가하지 않으면 오류가 발생합니다. 또한 AWS STS는 역할 신뢰 정책이 이 조건 키를 평가하지 않는 경우 권한 부여 요청을 거부합니다.
-
-
애플리케이션의 식별자를 입력합니다. 식별자의 레이블은 선택하는 제공업체를 기준으로 변경됩니다.
-
Login with Amazon용 역할을 생성하려는 경우 애플리케이션 ID(Application ID) 상자에 앱 ID를 입력합니다.
-
Facebook용 역할을 생성하려는 경우 애플리케이션 ID(Application ID) 상자에 앱 ID를 입력합니다.
-
Google용 역할을 생성하려는 경우 대상(Audience) 상자에 대상 사용자 이름을 입력합니다.
-
Amazon Cognito용 역할을 생성하려는 경우 Amazon Cognito 애플리케이션용으로 생성한 아이덴티티 풀의 ID를 자격 증명 풀 ID(Identity Pool ID) 상자에 입력합니다.
-
GitHub 작업을 위한 역할을 만들려는 경우 다음 세부 정보를 입력하세요.
-
대상(Audience)에서
sts.amazonaws.com
을 입력합니다. -
GitHub 조직에 GitHub 조직 이름을 입력합니다. GitHub 조직 이름은 필수이며 대시(-)를 포함한 영숫자여야 합니다. GitHub 조직 이름에 와일드카드 문자(* 및?)는 사용할 수 없습니다.
-
(선택 사항) GitHub 리포지토리에 GitHub 리포지토리 이름을 입력합니다. 값을 지정하지 않을 경우 기본값은 와일드카드(
*
)입니다. -
(선택 사항) GitHub 브랜치에 GitHub 브랜치 이름을 입력합니다. 값을 지정하지 않을 경우 기본값은 와일드카드(
*
)입니다.
-
-
HashiCorp Cloud Platform(HCP) Terraform에 대한 역할을 생성하려면 다음 세부 정보를 입력합니다.
-
대상(Audience)에서
aws.workload.identity
을 입력합니다. -
조직에 조직 이름을 입력합니다. 모든 조직에 와일드카드 문자(
*
)를 지정할 수 있습니다. -
프로젝트에 프로젝트 이름을 입력합니다. 모든 프로젝트에 와일드카드 문자(
*
)를 지정할 수 있습니다. -
WorkSpace에 WorkSpace 이름을 입력합니다. 모든 워크스페이스에 와일드카드 문자(
*
)를 지정할 수 있습니다. -
실행 단계에 실행 단계 이름을 입력합니다. 모든 실행 단계에 와일드카드 문자(
*
)를 지정할 수 있습니다.
-
-
-
(선택 사항) 애플리케이션 사용자가 역할에서 부여한 권한을 사용하기 위해 충족해야 하는 추가 조건을 만들려면 조건(선택 사항)에서 조건 추가를 클릭합니다. 예를 들어, 특정 IAM 사용자 ID에만 AWS 리소스에 대한 액세스 권한을 부여하는 조건을 추가할 수 있습니다. 역할을 만든 후에 신뢰 정책에 조건을 추가할 수도 있습니다. 자세한 내용은 역할 트러스트 정책 업데이트 단원을 참조하십시오.
-
OIDC 정보를 검토하고 다음을 선택합니다.
-
IAM은 계정의 AWS관리형 또는 고객 관리형 정책 목록을 포함합니다. 권한 정책을 사용하기 위한 정책을 선택하거나 정책 생성(Create policy)을 선택하여 새 브라우저 탭을 열고 완전히 새로운 정책을 생성합니다. 자세한 내용은 IAM 정책 생성 단원을 참조하세요. 정책을 생성하면 탭을 닫고 원래 탭으로 돌아갑니다. OIDC 사용자에게 부여하려는 권한 정책 옆의 확인란을 선택합니다. 원할 경우, 여기서 정책을 선택하지 않고 나중에 정책을 만들어서 역할에 연결할 수 있습니다. 기본적으로 역할은 권한이 없습니다.
-
(선택 사항) 권한 경계를 선택합니다. 이는 고급 기능입니다.
권한 경계(Permissions boundary) 섹션을 열고 최대 역할 권한을 관리하기 위한 권한 경계 사용(Use a permissions boundary to control the maximum role permissions)을 선택합니다. 정책을 선택하여 권한 경계를 사용하세요.
-
Next(다음)를 선택합니다.
-
역할 이름(Role name)에 역할 이름을 입력합니다. 역할 이름은 AWS 계정 내에서 고유해야 합니다. 대소문자를 구분하지 않습니다. 예를 들어, 이름이
PRODROLE
과prodrole
, 두 가지로 지정된 역할을 만들 수는 없습니다. 다른 AWS 리소스가 역할을 참조할 수 있기 때문에 역할을 생성한 후에는 역할 이름을 편집할 수 없습니다. -
(선택 사항) 설명(Description)에 새 역할에 대한 설명을 입력합니다.
-
역할에 대한 사용 사례와 권한을 편집하려면 1단계: 신뢰할 수 있는 엔터티 선택(Step 1: Select trusted entities) 또는 2단계: 권한 추가(Step 2: Add permissions) 섹션에서 편집(Edit)을 선택합니다.
-
(선택 사항) 역할에 메타데이터를 추가하려면 태그를 키-값 페어로 연결합니다. IAM에서의 태그 사용에 대한 자세한 내용은 AWS Identity and Access Management 리소스용 태그 섹션을 참조하세요.
-
역할을 검토한 다음 Create role을 선택합니다.
GitHub OIDC ID 제공자의 역할 구성
GitHub를 OIDC ID 제공업체(idP)로 사용하는 경우 IAM IdP와 연결된 역할을 수임할 수 있는 엔터티를 제한하는 것이 좋습니다. 신뢰 정책에 조건문을 포함하면 특정 GitHub 조직, 리포지토리 또는 분기로 역할을 제한할 수 있습니다. 문자열 조건 연산자가 있는 조건 키 token.actions.githubusercontent.com:sub
을(를) 사용하여 액세스를 제한할 수 있습니다. 특정 리포지토리 또는 GitHub 조직 내 리포지토리 또는 분기 세트로 조건을 제한하는 것이 좋습니다. GitHub의 OIDC를 페더레이션형 ID로 신뢰하도록 AWS를 구성하는 방법에 대한 자세한 내용을 알아보려면 GitHub Docs - Configuring OpenID Connect in Amazon Web Services
작업 워크플로나 OIDC 정책에서 GitHub 환경을 사용하는 경우 보안을 강화하기 위해 환경에 보호 규칙을 추가하는 것이 좋습니다. 배포 브랜치와 태그를 사용하여 환경에 배포할 수 있는 브랜치와 태그를 제한하세요. 보호 규칙을 사용하여 환경을 구성하는 방법에 대한 자세한 내용은 GitHub의 배포를 위한 환경 사용 문서의 배포 브랜치 및 태그
GitHub의 OIDC IdP가 사용자 역할의 신뢰할 수 있는 보안 주체인 경우 IAM은 역할 신뢰 정책 조건을 검사하여 조건 키 token.actions.githubusercontent.com:sub
이(가) 맞는지, 또 그 값이 와일드카드 문자(* 및 ?)만이거나 무효는 아닌지 확인합니다. IAM은 신뢰 정책이 생성되거나 업데이트될 때 이 검사를 수행합니다. 조건 키token.actions.githubusercontent.com:sub
이(가) 존재하지 않거나 키 값이 언급된 값 기준을 충족하지 않으면 요청이 실패하고 오류가 반환됩니다.
중요
조건 키 token.actions.githubusercontent.com:sub
을(를) 특정 조직이나 리포지토리에 한정하지 않으면 제어할 수 없는 조직이나 리포지토리의 GitHub 작업이 AWS 계정의 GitHub IAM IdP와 연결된 역할을 수임할 수 있습니다.
다음 예제 신뢰 정책은 정의된 GitHub 조직, 리포지토리 및 분기에 대한 액세스를 제한합니다. 아래 예에서 조건 키 token.actions.githubusercontent.com:sub
값은 GitHub에서 문서화한 기본 주제 값 형식입니다.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::012345678910:oidc-provider/token.actions.githubusercontent.com" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com", "token.actions.githubusercontent.com:sub": "repo:
GitHubOrg
/GitHubRepo
:ref:refs/heads/GitHubBranch
" } } } ] }
다음 예제 조건은 정의된 GitHub 조직 및 리포지토리에 대한 액세스를 제한하지만 리포지토리 내의 모든 분기에 대한 액세스 권한을 부여합니다.
"Condition": { "StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" }, "StringLike": { "token.actions.githubusercontent.com:sub": "repo:
GitHubOrg
/GitHubRepo
:*
" } }
다음 예제 조건은 정의된 GitHub 조직 내의 모든 리포지토리 또는 분기에 대한 액세스를 제한합니다. 조건 키 token.actions.githubusercontent.com:sub
은(는) GitHub 조직 내에서 GitHub 작업에 대한 액세스를 제한하는 특정 값으로 제한하는 것이 좋습니다.
"Condition": { "StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" }, "StringLike": { "token.actions.githubusercontent.com:sub": "repo:
GitHubOrg
/*
" } }
정책에서 조건 확인을 위해 사용 가능한 OIDC 페더레이션 키에 대한 자세한 정보는 AWS OIDC 페더레이션에서 사용 가능한 키 섹션을 참조하세요.