AWS 시크릿 엔진

AWS 시크릿 엔진 (AWS secrets engine)

IAM 정책을 기반으로 AWS 액세스 자격 증명을 동적으로 생성하는 AWS 시크릿 엔진을 다룹니다.

출처: 문서

본문

AWS 시크릿 엔진은 IAM 정책을 기반으로 AWS 액세스 자격 증명을 동적으로 생성해요. 이는 웹 UI를 클릭하는 일이 없어서 일반적으로 AWS IAM 작업을 더 쉽게 만들어 줍니다. 또한 프로세스가 코드화되어 LDAP 같은 내부 인증 방식에 매핑됩니다. AWS IAM 자격 증명은 시간 기반이며 Vault 리스가 만료되면 자동으로 폐기됩니다.

Vault는 AWS에서 가져올 네 가지 유형의 자격 증명을 지원합니다.

  1. iam_user — Vault가 각 리스마다 IAM 사용자를 만들고, 역할에 지정된 관리형·인라인 IAM 정책을 사용자에게 연결하고, permissions boundary가 역할에 지정되면 그것도 연결합니다. 그런 다음 Vault가 IAM 사용자에 대한 액세스 키와 시크릿 키를 생성해 호출자에게 반환합니다. IAM 사용자는 세션 토큰이 없어 세션 토큰이 반환되지 않습니다. Vault는 TTL 만료 시 IAM 사용자를 삭제해요.
  2. assumed_role — Vault가 sts:AssumeRole을 호출하고 액세스 키, 시크릿 키, 세션 토큰을 호출자에게 반환합니다.
  3. federation_token — Vault가 제공된 AWS 정책 문서를 전달하며 sts:GetFederationToken을 호출하고 액세스 키, 시크릿 키, 세션 토큰을 호출자에게 반환합니다.
  4. session_token — Vault가 sts:GetSessionToken을 호출하고 액세스 키, 시크릿 키, 세션 토큰을 호출자에게 반환합니다.

정적 역할 (Static roles)

AWS 시크릿 엔진은 "정적 역할(static roles)" 개념을 지원하는데, 이는 Vault 역할과 IAM 사용자를 1:1로 매핑한 것입니다. 사용자의 현재 비밀번호가 저장되고 Vault가 구성 가능한 기간으로 자동 회전합니다. 이것은 매 자격 증명 요청마다 고유한 사용자명·비밀번호 쌍이 생성되는 동적 시크릿과 대조됩니다. 역할에 대해 자격 증명이 요청되면 Vault는 구성된 사용자의 현재 Access Key ID와 Secret Access Key를 반환하여, 적절한 Vault 정책을 가진 누구나 IAM 자격 증명에 접근할 수 있게 해 줍니다.

이 기능에 대한 자세한 내용은 API documentation을 참고하세요.

설정 (Setup)

대부분의 시크릿 엔진은 제 기능을 하기 전에 미리 구성해야 해요. 이 단계는 보통 운영자나 구성 관리 도구가 수행합니다.

CLI — AWS 시크릿 엔진 활성화:

$ vault secrets enable aws
Success! Enabled the aws secrets engine at: aws/

기본적으로 시크릿 엔진은 엔진 이름으로 마운트돼요. 다른 경로에 활성화하려면 -path 인자를 사용하면 됩니다.

설정 중 기존 워크로드 아이덴티티 연합(WIF) 아이덴티티 토큰 키를 보려면 identity/oidc/key 엔드포인트에 대한 list 권한이 있어야 해요.

GUI: 1. Enable a Secrets Engine 페이지 열기 → 2. 네임스페이스 로그인 → 3. Secrets 선택 → 4. Secrets engines 선택 → 5. + Enable new engine 클릭 → Enable new engine + 클릭 → AWS 선택 → Next 클릭 → AWS 플러그인의 마운트 경로 설정(예: aws) → WIF를 사용한다면 Method Options → Identity Token Key에서 아이덴티티 토큰 키 추가 → Enable engine 클릭 → Save 클릭.

Vault가 AWS와 통신해 IAM 자격 증명을 생성하는 데 사용할 자격 증명 구성:

CLI:

$ vault write aws/config/root \
    access_key=AKIAJW...NLNA \
    secret_key=R4nm063hgMVo4BTT5xOs5nHLeLXA6lar7ZJ3Nt0i \
    region=us-east-1

GUI: 1. GUI 열기 → 2. 로그인 → 3. Secrets 선택 → 4. Secrets engines 선택 → 5. 업데이트할 aws 플러그인 선택 → 6. Configure 클릭 → 7. 구성 정보 입력 → 8. 접근 타입 설정 → (Enterprise) 9. 저장.

내부적으로 Vault는 이 자격 증명으로 AWS에 연결합니다. 따라서 이 자격 증명은 IAM 자격 증명에 부여될 수 있는 어떤 정책보다 상위 집합(superset) 이어야 합니다. Vault는 공식 AWS SDK를 사용하므로 지정된 자격 증명을 사용해요. 표준 AWS 환경 자격 증명, 공유 파일 자격 증명, IAM 역할/ECS 태스크 자격 증명으로도 지정할 수 있습니다. (STS Federation Tokens를 사용할 계획이라면 IAM 역할 자격 증명으로 vault를 인가할 수 없습니다. 역할과 연결된 임시 보안 자격 증명이 GetFederationToken을 사용하도록 인가되지 않기 때문이에요.)

경우에 따라 Vault 구성에 민감한 IAM 보안 자격 증명을 설정할 수 없을 수 있어요. 예를 들어 조직에서 모든 보안 자격 증명이 수명이 짧거나 머신 아이덴티티에 명시적으로 묶여야 할 수 있습니다.

Vault에 IAM 보안 자격 증명을 제공하려면 Vault plugin workload identity federation(WIF)을 사용할 것을 권장합니다.

주의: 위 경로는 aws/config/root지만 AWS 루트 계정 자격 증명을 사용하지 마세요. 대신 전용 사용자나 역할을 생성하세요.

또는 플러그인 워크로드 아이덴티티 연합을 위해 audience 클레임 값과 맡을 역할 ARN을 구성할 수 있어요.

CLI:

$ vault write aws/config/root \
    identity_token_audience="<AUDIENCE>" \
    role_arn="<ROLE_ARN>"

GUI: Access Type으로 Workload Identity Federation 선택하고 다음을 입력합니다.

  • Issuer URL — Vault 플러그인 아이덴티티 토큰 발급자의 완전하고 네트워크로 접근 가능한 발급자 URL. 예: https://vault.example.com/v1/identity/oidc/plugins.
  • Role ARN — 맡을 AWS IAM 역할의 ARN.
  • Identity token audience — 플러그인 아이덴티티 토큰의 audience 클레임 값. 이 값은 대상 Federated Identity Credential에 구성된 허용 audience와 일치해야 해요.

역할 설정 (Role setup)

Vault의 아이덴티티 토큰 제공자는 플러그인 아이덴티티 토큰 JWT를 내부적으로 서명합니다. Web Identity Federation을 통해 Vault와 AWS 사이에 신뢰 관계가 구성되어 있다면, 시크릿 엔진은 이 아이덴티티 토큰을 교환해 임시 STS 자격 증명을 얻을 수 있어요.

주의: 이 신뢰 관계가 확립되려면 AWS가 Vault 플러그인 identity token provider에 대한 완전하고 네트워크로 접근 가능한 Issuer URL 정보로 IAM OIDC identity provider를 구성해야 해요. 이는 AWS가 JWKS public keys를 가져와 플러그인 아이덴티티 토큰 서명을 검증하기 위함입니다. Vault의 Issuer를 구성하려면 Identity Tokens documentation을 참고하세요.

  1. AWS의 권한 집합과 AWS 자격 증명 유형에 매핑되는 Vault 역할을 구성해요. 사용자가 자격 증명을 생성하면 이 역할을 대상으로 생성됩니다. 예:
$ vault write aws/roles/my-role \
    credential_type=iam_user \
    policy_document=<<EOF
<POLICY_JSON>
EOF

이렇게 하면 "my-role"이라는 역할이 생성됩니다. 사용자가 이 역할에 대해 자격 증명을 생성하면 Vault가 IAM 사용자를 만들고 지정한 정책 문서를 IAM 사용자에게 연결합니다. 그런 다음 Vault가 IAM 사용자에 대한 액세스 키와 시크릿 키를 만들어 이 자격 증명을 반환합니다. 사용자 인라인 정책을 제공하거나 기존 AWS 정책의 전체 ARN에 대한 참조 및/또는 IAM 그룹 목록을 제공할 수 있어요.

$ vault write aws/roles/my-other-role \
    policy_arns=arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess,arn:aws:iam::aws:policy/IAMReadOnlyAccess \
    iam_groups=group1,group2 \
    credential_type=iam_user \
    policy_document=<<EOF
<POLICY_JSON>
EOF

IAM 정책에 대한 자세한 내용은 AWS IAM policy documentation을 참고하세요.

사용법 (Usage)

시크릿 엔진이 구성되고 사용자/머신이 적절한 권한을 가진 Vault 토큰을 가지면 자격 증명을 생성할 수 있어요.

  1. 역할 이름으로 /creds 엔드포인트를 읽어 새 자격 증명을 생성해요.
$ vault read aws/creds/my-role
Key                Value
---                -----
lease_id           aws/creds/my-role/f3e92392-7d9c-09c8-c921-575d62fe80d8
lease_duration     768h
lease_renewable    true
access_key         AKIAIO...7IEA
secret_key         iASuXNKcWKFtbO8Ef0vOcgtiL6knR20EJkJTH8WI
session_token

명령을 호출할 때마다 새 자격 증명이 생성돼요.

불행히도 IAM 자격 증명은 다른 Amazon 서비스에 대해 최종적으로 일관적(eventually consistent)입니다. 파이프라인에서 이 자격 증명을 사용할 계획이라면, 자격 증명을 가져온 후 성공적으로 사용하기 전에 5-10초(또는 그 이상)의 지연을 추가해야 할 수 있어요.

대기 없이 자격 증명을 사용하고 싶다면 STS 키 가져오기 방식을 고려해 보세요. STS 토큰이 지원하는 IAM 자격 증명은 생성되자마자 사용할 수 있습니다.

  1. Vault가 AWS와 통신하는 데 사용하는 자격 증명을 회전해요.
$ vault write -f aws/config/rotate-root
Key           Value
---           -----
access_key    AKIA3A...C8H4

참고: aws/config/rotate-root 호출 직후에는 AWS가 다시 일관적이 될 때까지 Vault에서 AWS로의 호출이 실패할 수 있어요. IAM 자격 증명 회전에 대한 추가 정보는 AWS secrets engine API 참조를 참고하세요.

일정 기반 루트 자격 증명 회전

Enterprise에요. 적절한 Vault Enterprise 라이선스가 필요합니다.

rotation_schedule 필드로 AWS 시크릿 엔진의 루트 자격 증명에 대한 일정 기반 자동 회전을 구성해요. 예:

$ vault write aws/config/root \
  ...
  rotation_schedule="0 * * * SAT"
  ...

예약된 루트 자격 증명 회전은 rotation_window도 설정할 수 있고, 회전이 발생하도록 허용되는 창입니다. Vault는 창이 만료되면 자격 증명 회전 시도를 중지합니다. 예:

$ vault write aws/config/root \
  ...
  rotation_window="1h" \
  rotation_schedule="0 * * * SAT"
  ...

disable_automated_rotation을 true로 설정해 루트 회전을 임시로 비활성화할 수 있어요. 이 필드가 false로 재설정될 때까지 루트 자격 증명의 회전을 방지합니다. rotation_period를 사용한다면 이 필드를 설정하면 자격 증명 TTL도 초기화됩니다.

AWS Secrets 엔진의 루트 자격 증명 회전에 대한 자세한 내용은 Root credential rotation API 문서를 참고하세요.

Vault용 IAM 권한 정책

credential_type=iam_user를 사용할 때 aws/config/root 자격 증명은 동적 IAM 사용자를 관리할 권한이 필요해요. Vault가 필요로 하는 가장 흔히 필요한 권한을 부여하는 예제 AWS IAM 정책은 다음과 같습니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "iam:AttachUserPolicy",
        "iam:CreateAccessKey",
        "iam:CreateUser",
        "iam:DeleteAccessKey",
        "iam:DeleteUser",
        "iam:DeleteUserPolicy",
        "iam:DetachUserPolicy",
        "iam:GetUser",
        "iam:ListAccessKeys",
        "iam:ListAttachedUserPolicies",
        "iam:ListGroupsForUser",
        "iam:ListUserPolicies",
        "iam:PutUserPolicy",
        "iam:AddUserToGroup",
        "iam:RemoveUserFromGroup",
        "iam:TagUser"
      ],
      "Resource": ["arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:user/vault-*"]
    }
  ]
}

Vault는 IAM 사용자를 만들 때 AWS Permissions Boundaries도 지원합니다. Vault가 항상 permissions boundary를 IAM 사용자에게 연결하도록 강제하고 싶다면 다음과 같은 정책을 사용할 수 있습니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "iam:CreateAccessKey",
        "iam:DeleteAccessKey",
        "iam:DeleteUser",
        "iam:GetUser",
        "iam:ListAccessKeys",
        "iam:ListAttachedUserPolicies",
        "iam:ListGroupsForUser",
        "iam:ListUserPolicies",
        "iam:AddUserToGroup",
        "iam:RemoveUserFromGroup"
      ],
      "Resource": ["arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:user/vault-*"]
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:AttachUserPolicy",
        "iam:CreateUser",
        "iam:DeleteUserPolicy",
        "iam:DetachUserPolicy",
        "iam:PutUserPolicy"
      ],
      "Resource": ["arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:user/vault-*"],
      "Condition": {
        "StringEquals": {
          "iam:PermissionsBoundary": [
            "arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:policy/PolicyName"
          ]
        }
      }
    }
  ]
}

여기서 "iam:PermissionsBoundary" 조건에는 Vault가 사용하기를 원하는 permissions boundary 정책 목록이 들어 있어요. 이 정책은 Vault가 지정된 permissions boundary 중 하나(모두가 아니라)를 사용하게 보장합니다.

STS 자격 증명용 정책

AWS 루트 자격 증명(aws/config/root)은 assumed_role, session_token, federation_token 같은 STS 자격 증명을 사용할 때 동적 IAM 사용자를 관리할 권한이 필요하지 않아요.

rotate 엔드포인트로 STS 자격 증명을 사용해 IAM 사용자 자격 증명을 회전하려면 IAM 사용자 자체에 다음 권한을 부여해야 해요.

{
  "Statement": [
    {
      "Action": [
        "iam:ListAccessKeys",
        "iam:GetUser",
        "iam:DeleteAccessKey",
        "iam:CreateAccessKey"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:user/vault-iam-user"
    }
  ],
  "Version": "2012-10-17"
}

플러그인 워크로드 아이덴티티 연합 (Plugin Workload Identity Federation / WIF)

Enterprise에요. 이 기능은 Vault Enterprise가 필요합니다.

AWS 시크릿 엔진은 플러그인 WIF 워크플로를 지원하며, 플러그인 아이덴티티 토큰이라는 신원 소스를 가집니다. 플러그인 아이덴티티 토큰은 Vault의 plugin identity token issuer가 내부적으로 서명하는 JWT입니다.

Web Identity Federation을 통해 Vault와 AWS 사이에 신뢰 관계가 구성되어 있다면, 시크릿 엔진은 자신의 아이덴티티 토큰을 작업을 수행하는 데 필요한 단기 STS 자격 증명으로 교환할 수 있어요.

아이덴티티 토큰을 STS 자격 증명으로 교환하면 AWS 시크릿 엔진이 민감한 IAM 보안 자격 증명에 대한 명시적 접근을 구성하지 않고도 동작할 수 있습니다.

시크릿 엔진을 플러그인 WIF로 구성하려면:

  1. Vault openid-configuration과 public JWKS API가 AWS에서 네트워크로 접근 가능한지 확인해요.
  2. AWS에서 IAM OIDC identity provider를 만들어요.
    1. 제공자 URL은 반드시 /.well-known/openid-configuration 접미사를 뺀 Vault plugin identity token issuer를 가리켜야 해요. 예: https://host:port/v1/identity/oidc/plugins.
    2. audience는 플러그인 아이덴티티 토큰의 수신자를 고유하게 식별해야 해요. AWS에서 수신자는 아이덴티티 제공자입니다. 제공자 URL의 host:port/v1/identity/oidc/plugins 부분을 수신자로 사용할 것을 권장합니다. 구성된 각 아이덴티티 제공자마다 고유하기 때문이에요.
  3. IAM OIDC 아이덴티티 제공자에 사용한 것과 같은 audience로 AWS에서 web identity role을 만들어요.
  4. AWS 시크릿 엔진을 IAM OIDC audience 값과 웹 아이덴티티 역할 ARN으로 구성해요.
$ vault write aws/config/root \
    identity_token_audience="vault.example/v1/identity/oidc/plugins" \
    role_arn="arn:aws:iam::123456789123:role/example-web-identity-role"

이제 시크릿 엔진은 구성 자격 증명에 플러그인 WIF를 사용할 수 있습니다. 기본적으로 WIF 자격 증명은 수명이 1시간이며 만료되면 자동으로 갱신됩니다.

플러그인 WIF와 관련된 필드에 대한 자세한 내용은 API documentation을 참고하세요.

크로스 계정 정적 역할 관리

Enterprise에요. 적절한 Vault Enterprise 라이선스가 필요합니다.

Vault는 AWS 정적 역할에 대한 크로스 계정 접근을 지원합니다. 다른 계정에서 역할을 맡아 여러 AWS 계정의 IAM 사용자 자격 증명 관리를 구성할 수 있어요.

크로스 계정 정적 역할을 구성하려면:

  1. Vault가 AWS STS와 IAM 엔드포인트에 접근할 수 있는지 확인해요.
  2. 대상 AWS 계정에 Vault가 맡을 수 있는 IAM 역할을 만들어요. 그 역할은 Vault AWS 계정이 맡는 것을 신뢰하고 IAM 사용자를 관리할 필요한 IAM 권한이 있어야 합니다.
  3. (선택이지만 권장) 향상된 보안을 위해 external ID를 설정해요.
  4. Vault에서 정적 역할을 만들어요.
    1. assume_role_arn 필드로 대상 계정 ARN을 설정.
    2. assume_role_session_name 필드로 대상 계정 세션 이름을 설정.
$ vault write aws/static-roles/<ROLE_NAME> \
    username="<USERNAME>" \
    assume_role_arn="arn:aws:iam::<ACCOUNT_ID>:role/<ROLE>" \
    assume_role_session_name="<SESSION_NAME>" \
    external_id="<EXTERNAL_ID>" \
    rotation_period="1h"

구성되면 Vault는:

  1. 대상 AWS 계정에서 지정된 역할을 맡습니다.
  2. 지정된 rotation_period에 따라 IAM 사용자의 자격 증명을 관리·회전합니다.
  3. aws/static-creds/으로 요청하면 IAM 사용자의 액세스 키와 시크릿 키를 반환합니다.

정적 역할의 크로스 계정 관리와 관련된 필드에 대한 자세한 내용은 create and update static role endpoint documentation을 참고하세요.

STS 자격 증명

위는 iam_user 자격 증명 유형을 사용한 사용법을 보여줬습니다. 앞서 언급했듯 Vault는 assumed_role, federation_token, session_token 자격 증명 유형도 지원합니다.

STS federation 토큰

주의: AWS의 제한 때문에 federation_token 자격 증명 유형을 사용하려면 Vault가 반드시 IAM 사용자 자격 증명으로 구성되어야 합니다. AWS는 임시 자격 증명(예: IAM 인스턴스 프로파일의 자격 증명)을 사용하는 것을 허용하지 않아요.

STS federation 토큰은 네 집합의 권한의 조합(교집합)인 권한 집합을 상속합니다.

  1. aws/config/root 자격 증명에 부여된 권한
  2. Vault 역할에 구성된 사용자 인라인 정책
  3. Vault 역할에 구성된 관리형 정책 ARN
  4. IAM 또는 STS 작업에 대한 암시적 deny 정책

credential_type이 federation_token인 역할은 Vault 역할에서 policy_document, policy_arns, iam_groups 파라미터 중 하나 이상을 지정할 수 있어요.

aws/config/root 자격 증명은 sts:GetFederationToken에 대한 IAM 권한과 STS federation 토큰에 위임할 권한이 필요해요. 예를 들어 aws/config/root 자격 증명에 대한 이 정책은 위임된 ec2:* 권한(또는 ec2:*의 하위 집합)으로 STS federated 토큰 생성을 허용합니다.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": [
      "ec2:*",
      "sts:GetFederationToken"
    ],
    "Resource": "*"
  }
}

그러면 ec2_admin 역할에 같은 ec2:* 권한을 가진 인라인 정책을 할당합니다.

$ vault write aws/roles/ec2_admin \
    credential_type=federation_token \
    [email protected]

policy.json 파일에는 sts:GetFederationToken 권한을 뺀 비슷한 권한을 가진 인라인 정책이 담깁니다. (sts:GetFederationToken 권한을 부여할 수는 있지만, STS가 allow를 오버라이드하는 암시적 deny를 붙입니다.)

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "ec2:*",
    "Resource": "*"
  }
}

새 STS federation 토큰 자격 증명 집합을 생성하려면 aws/sts 엔드포인트를 사용해 역할에 쓰면 됩니다.

$ vault write aws/sts/ec2_admin ttl=60m
Key             Value
lease_id        aws/sts/ec2_admin/31d771a6-fb39-f46b-fdc5-945109106422
lease_duration  60m0s
lease_renewable false
access_key      ASIAJYYYY2AA5K4WIXXX
secret_key      HSs0DYYYYYY9W81DXtI0K7X84H+OVZXK5BXXXX
session_token   AQoDYXdzEEwasAKwQyZUtZaCjVNDiXXXXXXXXgUgBBVUUbSyujLjsw6jYzboOQ89vUVIehUw/9MreAifXFmfdbjTr3g6zc0me9M+dB95DyhetFItX5QThw0lEsVQWSiIeIotGmg7mjT1//e7CJc4LpxbW707loFX1TYD1ilNnblEsIBKGlRNXZ+QJdguY4VkzXxv2urxIH0Sl14xtqsRPboV7eYruSEZlAuP3FLmqFbmA0AFPCT37cLf/vUHinSbvw49C4c9WQLH7CeFPhDub7/rub/QU/lCjjJ43IqIRo9jYgcEvvdRkQSt70zO8moGCc7pFvmL7XGhISegQpEzudErTE/PdhjlGpAKGR3d5qKrHpPYK/k480wk1Ai/t1dTa/8/3jUYTUeIkaJpNBnupQt7qoaXXXXXXXXXX

STS 세션 토큰

session_token 자격 증명 유형은 root 구성 하의 단기 자격 증명을 생성하는 데 사용됩니다. Vault와 AWS로 이들을 만들려면 Vault가 IAM 사용자 자격 증명을 사용하도록 구성해야 해요. AWS는 IAM 인스턴스 프로파일의 임시 자격 증명 같은 것을 사용해 세션 토큰을 생성하는 것을 허용하지 않습니다.

경고: STS 세션 토큰은 aws/config/root에 구성된 사용자에게 부여된 모든 권한을 상속합니다. 이 예제에서 temp_user 역할은 root 구성과 같은 ec2:* 권한을 가진 정책을 얻습니다. 그렇기 때문에 이 자격 증명 유형에는 역할·정책 할당이 허용되지 않습니다.

$ vault write aws/roles/temp_user \
    credential_type=session_token

새 STS federation 토큰 자격 증명 집합을 생성하려면 aws/creds 엔드포인트를 사용해 temp_user 역할에 씁니다.

$ vault read aws/sts/temp_user ttl=60m
Key             Value
lease_id        aws/creds/temp_user/w4eKbMaJOi1xLqG3MWk7y8n6
lease_duration  60m0s
lease_renewable false
access_key      ASIAJYYYY2AA5K4WIXXX
secret_key      HSs0DYYYYYY9W81DXtI0K7X84H+OVZXK5BXXXX
session_token   AQoDYXdzEEwasAKwQyZUtZaCjVNDiXXXXXXXXgUgBBVUUbSyujLjsw6jYzboOQ89vUVIehUw/9MreAifXFmfdbjTr3g6zc0me9M+dB95DyhetFItX5QThw0lEsVQWSiIeIotGmg7mjT1//e7CJc4LpxbW707loFX1TYD1ilNnblEsIBKGlRNXZ+QJdguY4VkzXxv2urxIH0Sl14xtqsRPboV7eYruSEZlAuP3FLmqFbmA0AFPCT37cLf/vUHinSbvw49C4c9WQLH7CeFPhDub7/rub/QU/lCjjJ43IqIRo9jYgcEvvdRkQSt70zO8moGCc7pFvmL7XGhISegQpEzudErTE/PdhjlGpAKGR3d5qKrHpPYK/k480wk1Ai/t1dTa/8/3jUYTUeIkaJpNBnupQt7qoaXXXXXXXXXX

세션 토큰은 IAM 사용자가 요구하도록 구성된 경우 MFA 기반 TOTP가 필요할 수도 있어요. 그러면 Vault 역할에 MFA 디바이스 일련 번호가 설정되어야 하고, TOTP는 Vault 역할에서 자격 증명을 읽을 때 제공될 수 있어요.

$ vault write aws/roles/mfa_user \
    credential_type=session_token \
    mfa_serial_number="arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:mfa/device-name"

$ vault read aws/creds/mfa_user mfa_code=123456

STS AssumeRole

assumed_role 자격 증명 유형은 일반적으로 크로스 계정 인증 또는 SSO(단일 로그온) 시나리오에 사용됩니다. assumed_role 자격 증명 유형을 사용하려면 Vault 밖에서 다음을 구성해야 합니다.

  1. IAM 역할
  2. IAM 역할에 연결된 IAM 인라인 정책 및/또는 관리형 정책
  3. Vault가 역할을 맡을 권한을 부여하는 IAM 역할에 연결된 IAM 신뢰 정책

assumed_role 자격 증명은 federation_token보다 몇 가지 이점을 제공합니다.

  1. Assumed roles는 역할의 IAM 정책이 부여하면 IAM 및 STS 작업을 호출할 수 있습니다.
  2. Assumed roles는 크로스 계정 인증을 지원합니다.
  3. 임시 자격 증명(예: IAM 인스턴스 프로파일의 EC2 인스턴스에서 Vault를 실행하여 부여된 자격 증명)은 assumed_role 자격 증명을 가져올 수 있지만(단, federation_token 자격 증명은 가져올 수 없음) federation_token 자격 증명은 가져올 수 없습니다.

aws/config/root 자격 증명은 두 가지 방법 중 하나로 sts:AssumeRole이 허용되어야 합니다.

  1. 자격 증명에 대상 역할에 대해 연결된 IAM 정책:
{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:role/RoleNameToAssume"
  }
}
  1. 주체(principal)에 대해 대상 IAM 역할에 연결된 신뢰 정책:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:user/VAULT-AWS-ROOT-CONFIG-USER-NAME"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

credential_type이 assumed_role인 Vault 역할을 지정할 때 하나 이상의 IAM 역할 ARN을 지정할 수 있어요. 그렇게 하면 Vault 클라이언트는 그 역할에서 자격 증명을 가져올 때 맡을 역할 ARN을 선택할 수 있습니다.

또한 policy_document와 policy_arns 파라미터를 모두 지정할 수 있고, 지정하면 각각이 assumed role에 부여된 IAM 권한에 대한 필터 역할을 합니다. iam_groups가 지정되면 sts:AssumeRole을 호출할 때 각 IAM 그룹의 인라인·연결 정책이 각각 policy_document와 policy_arns 파라미터에 추가됩니다. 작업이 허용되려면 맡는 AWS 역할의 IAM 정책, Vault 역할에 지정된 policy_document(지정된 경우), policy_arns 파라미터가 지정한 관리형 정책 모두가 그 작업을 허용해야 합니다. (policy_document 파라미터는 sts:AssumeRole API 호출의 Policy 파라미터로 전달되고, policy_arns 파라미터는 같은 호출의 PolicyArns 파라미터로 전달됩니다.)

참고: 여러 role_arns를 지정하면 자격 증명을 요청하는 클라이언트가 Vault 역할에 정의된 role ARN 중 아무 것이나 지정해 자격 증명을 가져올 수 있습니다. 그러나 policy_document, policy_arns, iam_groups를 지정하면 그 값이 AWS에서 가져온 모든 역할 자격 증명에 적용됩니다.

맡을 역할의 arn을 사용해 "deploy" 정책을 만들어 보겠습니다.

$ vault write aws/roles/deploy \
    role_arns=arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:role/RoleNameToAssume \
    credential_type=assumed_role

새 STS assumed role 자격 증명 집합을 생성하려면 다시 aws/sts 엔드포인트를 사용해 역할에 씁니다.

$ vault write aws/sts/deploy ttl=60m
Key             Value
lease_id        aws/sts/deploy/31d771a6-fb39-f46b-fdc5-945109106422
lease_duration  60m0s
lease_renewable false
access_key      ASIAJYYYY2AA5K4WIXXX
secret_key      HSs0DYYYYYY9W81DXtI0K7X84H+OVZXK5BXXXX
session_token   AQoDYXdzEEwasAKwQyZUtZaCjVNDiXXXXXXXXgUgBBVUUbSyujLjsw6jYzboOQ89vUVIehUw/9MreAifXFmfdbjTr3g6zc0me9M+dB95DyhetFItX5QThw0lEsVQWSiIeIotGmg7mjT1//e7CJc4LpxbW707loFX1TYD1ilNnblEsIBKGlRNXZ+QJdguY4VkzXxv2urxIH0Sl14xtqsRPboV7eYruSEZlAuP3FLmqFbmA0AFPCT37cLf/vUHinSbvw49C4c9WQLH7CeFPhDub7/rub/QU/lCjjJ43IqIRo9jYgcEvvdRkQSt70zO8moGCc7pFvmL7XGhISegQpEzudErTE/PdhjlGpAKGR3d5qKrHpPYK/k480wk1Ai/t1dTa/8/3jUYTUeIkaJpNBnupQt7qoaXXXXXXXXXX

트러블슈팅

동적 IAM 사용자 오류

다음 중 하나와 비슷한 오류 메시지가 나온다면 aws/config/root에 쓴 루트 자격 증명에 권한이 부족한 것입니다.

$ vault read aws/creds/deploy
* Error creating IAM user: User: arn:aws:iam::000000000000:user/hashicorp is not authorized to perform: iam:CreateUser on resource: arn:aws:iam::000000000000:user/vault-root-1432735386-4059

$ vault revoke aws/creds/deploy/774cfb27-c22d-6e78-0077-254879d1af3c
Revoke error: Error making API request.

URL: POST http://127.0.0.1:8200/v1/sys/revoke/aws/creds/deploy/774cfb27-c22d-6e78-0077-254879d1af3c
Code: 400. Errors:

* invalid request

언제든 막히면 vault path-help aws 또는 하위 경로로 대화형 도움말 출력을 실행하세요.

STS federated 토큰 오류

Vault는 aws/config에 전달된 IAM 자격 증명으로 STS 토큰을 생성합니다.

그 자격 증명은 두 가지 속성을 가져야 합니다.

  • sts:GetFederationToken을 호출할 권한이 있어야 합니다.
  • 그 자격 증명의 능력은 STS creds에 연결된 정책이 요청하는 것 이상으로 허용적이어야 합니다.

두 조건 중 하나라도 충족되지 않으면 "403 not-authorized" 오류가 반환됩니다.

자세한 내용은 http://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html을 참고하세요.

STS 토큰을 사용할 때는 STS 토큰 이름의 AWS 32자 제한을 초과하는 검증 오류를 피하려면 Vault 0.5.1 이상을 권장합니다.

AWS 문자 제한에는 경로가 포함됩니다. 토큰 이름의 AWS 문자 제한에는 토큰의 전체 경로가 포함됩니다. 예를 들어 aws/sts/dev005_vault-test_testtest(34자)는 제한을 초과하지만 aws/roles/dev005_vaulttest-test(31자)는 초과하지 않습니다.

AWS 인스턴스 메타데이터 타임아웃

Vault 1.4 이상에 영향

EC2 인스턴스에서 Vault가 인스턴스 메타데이터 서비스를 사용할 때마다(예: 인스턴스 프로파일에서 자격 증명을 가져올 때), 인스턴스 메타데이터 서비스 v2(IMDSv2) 도입으로 지연이 있을 수 있습니다. Vault가 사용하는 AWS SDK는 먼저 IMDSv2에 연결을 시도하고, 타임아웃되면 v1로 폴백합니다. Vault 1.4에서는 이 타임아웃이 최대 2분 걸릴 수 있어요. Vault 1.5.5 이상에서는 이 수정으로 최대 2초가 걸릴 수 있습니다.

타임아웃은 Vault와 IMDSv2 사이에 프록시가 있고 인스턴스 홉 제한이 Vault와 IMDSv2 사이의 "홉" 수보다 적게 설정된 상황에서 발생합니다. 예를 들어 인스턴스 홉 제한이 1로 설정된 EC2 인스턴스의 docker에서 Vault를 실행 중이라면, docker와 IMDS 사이의 추가 네트워크 홉 때문에 AWS SDK 클라이언트가 IMDSv2에 연결을 시도하고, 타임아웃되고 IMDSv1로 폴백합니다.

타임아웃 동작을 피하려면 홉 제한을 기본 EC2 인스턴스에서 조정할 수 있어요. docker 예제에서 홉 제한을 2로 설정하면 Vault의 AWS SDK가 지연 없이 IMDSv2에 연결할 수 있습니다.

API

AWS 시크릿 엔진은 완전한 HTTP API를 제공해요. 자세한 내용은 AWS secrets engine API를 참고하세요.

Terraform

Vault Terraform 제공자로 AWS 시크릿 리소스를 프로그래밍 방식으로 관리할 수 있어요. Terraform Registry 문서에서 자세한 내용을 확인하세요.

더 알아보기 (Learn more)