InfoGrab Docs

AWS에서 임시 자격 증명을 검색하기 위한 OpenID Connect 구성

요약

CI_JOB_JWT_V2는 GitLab 15.9에서 더 이상 사용되지 않음으로 표시되었으며 GitLab 17.0에서 제거될 예정입니다. 이 튜토리얼에서는 JSON 웹 토큰(JWT)과 함께 GitLab CI/CD 작업을 사용하여 시크릿을 저장하지 않고 AWS에서 임시 자격 증명을 검색하는 방법을 보여줍니다.

Warning

CI_JOB_JWT_V2는 GitLab 15.9에서 더 이상 사용되지 않음으로 표시되었으며 GitLab 17.0에서 제거될 예정입니다. 대신 ID 토큰을 사용하세요.

이 튜토리얼에서는 JSON 웹 토큰(JWT)과 함께 GitLab CI/CD 작업을 사용하여 시크릿을 저장하지 않고 AWS에서 임시 자격 증명을 검색하는 방법을 보여줍니다. 이를 위해 GitLab과 AWS 간의 ID 페더레이션을 위한 OpenID Connect(OIDC)를 구성해야 합니다. OIDC를 사용하여 GitLab을 통합하기 위한 배경 및 요구 사항은 클라우드 서비스에 연결을 참조하세요.

이 튜토리얼을 완료하려면:

  1. ID 공급자 추가
  2. 역할 및 신뢰 구성
  3. 임시 자격 증명 검색

ID 공급자 추가#

다음 지침에 따라 AWS에서 GitLab을 IAM OIDC 공급자로 생성합니다.

다음 정보를 포함합니다:

  • 공급자 URL: https://gitlab.com 또는 http://gitlab.example.com과 같은 GitLab 인스턴스 주소. 이 주소는 공개적으로 접근 가능해야 합니다. 공개적으로 접근 불가능한 경우, 공개되지 않은 GitLab 인스턴스 구성 방법을 참조하세요.

  • 대상: 요청된 보안 토큰과 함께 사용하려는 대상 서비스의 논리적 이름.

    • AWS OIDC 통합에서, 이는 일반적으로 IAM OIDC ID 공급자에 구성된 대상 값과 일치합니다(종종 sts.amazonaws.com 또는 GitLab 인스턴스 URL).
    • 이 값은 토큰이 특정 ID 공급자를 위한 것임을 확인하기 위해 AWS에서 검증됩니다.

    [!note] https://gitlab.com 또는 GitLab 인스턴스 URL은 AWS ID 공급자 참조가 일치하는 경우 작동할 수 있지만, 의미상으로는 잘못된 것입니다. 대상은 토큰을 검증하고 수락하는 서비스를 나타내야 합니다.

역할 및 신뢰 구성#

ID 공급자를 생성한 후, GitLab 리소스에 대한 접근을 제한하는 조건과 함께 웹 ID 역할을 구성합니다. 임시 자격 증명은 AWS Security Token Service를 사용하여 얻으므로, Action을 sts:AssumeRoleWithWebIdentity로 설정합니다.

특정 그룹, 프로젝트, 브랜치 또는 태그로 권한 부여를 제한하기 위해 역할에 대한 사용자 지정 신뢰 정책을 만들 수 있습니다. 지원되는 필터링 유형의 전체 목록은 클라우드 서비스에 연결을 참조하세요.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::AWS_ACCOUNT:oidc-provider/gitlab.example.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "gitlab.example.com:sub": "project_path:mygroup/myproject:ref_type:branch:ref:main"
        }
      }
    }
  ]
}

역할이 생성된 후, AWS 서비스(S3, EC2, Secrets Manager)에 대한 권한을 정의하는 정책을 연결합니다.

임시 자격 증명 검색#

OIDC와 역할을 구성한 후, GitLab CI/CD 작업은 AWS Security Token Service(STS)에서 임시 자격 증명을 검색할 수 있습니다.

assume role:
  id_tokens:
    GITLAB_OIDC_TOKEN:
      aud: https://gitlab.example.com
  script:
    # 올바른 종료 코드 처리를 위해 분리됨
    - >
      aws_sts_output=$(aws sts assume-role-with-web-identity
      --role-arn ${ROLE_ARN}
      --role-session-name "GitLabRunner-${CI_PROJECT_ID}-${CI_PIPELINE_ID}"
      --web-identity-token ${GITLAB_OIDC_TOKEN}
      --duration-seconds 3600
      --query 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken]'
      --output text)
    - export $(printf "AWS_ACCESS_KEY_ID=%s AWS_SECRET_ACCESS_KEY=%s AWS_SESSION_TOKEN=%s" $aws_sts_output)
    - aws sts get-caller-identity
  • ROLE_ARN: 이 단계에서 정의된 역할 ARN.
  • GITLAB_OIDC_TOKEN: OIDC ID 토큰.

작동 예시#

공개되지 않은 GitLab 인스턴스 구성#

히스토리
Warning

이 해결 방법은 이해해야 할 보안 고려 사항이 있는 고급 구성 옵션입니다. 개인 GitLab Self-Managed 인스턴스에서 S3 버킷과 같은 공개적으로 사용 가능한 위치로 OpenID 구성 및 공개 키를 올바르게 동기화해야 합니다. 또한 S3 버킷과 내부 파일이 적절히 보안되어 있는지 확인해야 합니다. S3 버킷을 제대로 보안하지 못하면 이 OpenID Connect ID와 연결된 클라우드 계정이 탈취될 수 있습니다.

GitLab 인스턴스에 공개적으로 접근할 수 없는 경우, 기본적으로 AWS에서 OpenID Connect를 구성할 수 없습니다. 일부 특정 구성을 공개적으로 접근 가능하게 만들어 인스턴스에 대한 OpenID Connect 구성을 활성화하는 해결 방법을 사용할 수 있습니다:

  1. 공개적으로 사용 가능한 위치(예: S3 파일)에 GitLab 인스턴스의 인증 세부 정보를 저장합니다:

    • S3 파일에서 인스턴스의 OpenID 구성을 호스팅합니다. 구성은 http://gitlab.example.com/.well-known/openid-configuration과 같이 /.well-known/openid-configuration에서 사용 가능합니다. 공개적으로 사용 가능한 위치를 가리키도록 구성 파일의 issuer: 및 jwks_uri: 값을 업데이트합니다.
    • S3 파일에서 인스턴스 URL의 공개 키를 호스팅합니다. 키는 http://gitlab.example.com/oauth/discovery/keys와 같이 /oauth/discovery/keys에서 사용 가능합니다.

    예시:

    • OpenID 구성 파일: https://example-oidc-configuration-s3-bucket.s3.eu-north-1.amazonaws.com/.well-known/openid-configuration.
    • JWKS(JSON 웹 키 세트): https://example-oidc-configuration-s3-bucket.s3.eu-north-1.amazonaws.com/oauth/discovery/keys.
    • ID 토큰의 발급자 클레임 iss: 및 OpenID 구성의 issuer: 값은 다음과 같습니다: https://example-oidc-configuration-s3-bucket.s3.eu-north-1.amazonaws.com

  2. 선택 사항. OpenID 구성 엔드포인트 유효성 검사기와 같은 OpenID 구성 유효성 검사기를 사용하여 공개적으로 사용 가능한 OpenID 구성의 유효성을 검사합니다.

  3. ID 토큰에 대한 사용자 지정 발급자 클레임을 구성합니다. 기본적으로 GitLab ID 토큰은 발급자 클레임 iss:가 GitLab 인스턴스 주소로 설정됩니다(예: http://gitlab.example.com).

  4. 발급자 URL을 업데이트합니다:

  5. /etc/gitlab/gitlab.rb를 편집합니다:

    gitlab_rails['ci_id_tokens_issuer_url'] = '<public_url_with_openid_configuration_and_keys>'

    <public_url_with_openid_configuration_and_keys>를 https://example-oidc-configuration-s3-bucket.s3.eu-north-1.amazonaws.com과 같은 URL로 교체합니다.

    1. 파일을 저장하고 변경 사항이 적용되도록 GitLab을 재구성합니다.

  1. Helm 값을 내보냅니다:

    helm get values gitlab > gitlab_values.yaml

    1. gitlab_values.yaml을 편집합니다:

      global:
  appConfig:
    ciIdTokens:
      issuerUrl: '<public_url_with_openid_configuration_and_keys>'

      <public_url_with_openid_configuration_and_keys>를 https://example-oidc-configuration-s3-bucket.s3.eu-north-1.amazonaws.com과 같은 URL로 교체합니다.

    2. 파일을 저장하고 새 값을 적용합니다:

      helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab

  1. docker-compose.yml을 편집합니다:

    version: "3.6"
services:
  gitlab:
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        gitlab_rails['ci_id_tokens_issuer_url'] = '<public_url_with_openid_configuration_and_keys>'

    <public_url_with_openid_configuration_and_keys>를 https://example-oidc-configuration-s3-bucket.s3.eu-north-1.amazonaws.com과 같은 URL로 교체합니다.

    1. 파일을 저장하고 GitLab을 재시작합니다:

      docker compose up -d

  1. /home/git/gitlab/config/gitlab.yml을 편집합니다:

     production: &base
   ci_id_tokens:
     issuer_url: '<public_url_with_openid_configuration_and_keys>'

    <public_url_with_openid_configuration_and_keys>를 https://example-oidc-configuration-s3-bucket.s3.eu-north-1.amazonaws.com과 같은 URL로 교체합니다.

    1. 파일을 저장하고 변경 사항이 적용되도록 GitLab을 재구성합니다.
  1. ci:validate_id_token_configuration Rake 태스크를 실행하여 CI/CD ID 토큰 구성의 유효성을 검사합니다.

문제 해결#

오류: Not authorized to perform sts:AssumeRoleWithWebIdentity#

이 오류가 발생하는 경우:

An error occurred (AccessDenied) when calling the AssumeRoleWithWebIdentity operation:
Not authorized to perform sts:AssumeRoleWithWebIdentity

여러 가지 이유로 발생할 수 있습니다:

Could not connect to openid configuration of provider 오류#

AWS IAM에 ID 공급자를 추가한 후 다음 오류가 발생할 수 있습니다:

Your request has a problem. Please see the following details.
  - Could not connect to openid configuration of provider: `https://gitlab.example.com`

이 오류는 OIDC ID 공급자의 발급자가 순서가 잘못되었거나 중복 또는 추가 인증서가 포함된 인증서 체인을 제공할 때 발생합니다.

GitLab 인스턴스의 인증서 체인을 확인합니다. 체인은 도메인 또는 발급자 URL로 시작하여 중간 인증서, 루트 인증서로 끝나야 합니다. 다음 명령을 사용하여 gitlab.example.com을 GitLab 호스트 이름으로 바꿔 인증서 체인을 검토합니다:

echo | /opt/gitlab/embedded/bin/openssl s_client -connect gitlab.example.com:443

Couldn't retrieve verification key from your identity provider 오류#

다음과 유사한 오류가 발생할 수 있습니다:

이 오류의 원인:

이 오류에 대한 AWS Knowledge Center 문서에 문서화된 것처럼 GitLab 인스턴스는 .well_known URL 및 jwks_uri를 확인할 수 있도록 공개적으로 접근 가능해야 합니다. 예를 들어 GitLab 인스턴스가 오프라인 환경에 있는 경우, 공개되지 않은 GitLab 인스턴스 구성 방법을 참조하세요.

AWS에서 임시 자격 증명을 검색하기 위한 OpenID Connect 구성

Tier: Free, Premium, Ultimate
Offering: GitLab Self-Managed
원문 보기
요약

CI_JOB_JWT_V2는 GitLab 15.9에서 더 이상 사용되지 않음으로 표시되었으며 GitLab 17.0에서 제거될 예정입니다. 이 튜토리얼에서는 JSON 웹 토큰(JWT)과 함께 GitLab CI/CD 작업을 사용하여 시크릿을 저장하지 않고 AWS에서 임시 자격 증명을 검색하는 방법을 보여줍니다.

Warning

CI_JOB_JWT_V2는 GitLab 15.9에서 더 이상 사용되지 않음으로 표시되었으며 GitLab 17.0에서 제거될 예정입니다. 대신 ID 토큰을 사용하세요.

이 튜토리얼에서는 JSON 웹 토큰(JWT)과 함께 GitLab CI/CD 작업을 사용하여 시크릿을 저장하지 않고 AWS에서 임시 자격 증명을 검색하는 방법을 보여줍니다. 이를 위해 GitLab과 AWS 간의 ID 페더레이션을 위한 OpenID Connect(OIDC)를 구성해야 합니다. OIDC를 사용하여 GitLab을 통합하기 위한 배경 및 요구 사항은 클라우드 서비스에 연결을 참조하세요.

이 튜토리얼을 완료하려면:

  1. ID 공급자 추가
  2. 역할 및 신뢰 구성
  3. 임시 자격 증명 검색

ID 공급자 추가#

다음 지침에 따라 AWS에서 GitLab을 IAM OIDC 공급자로 생성합니다.

다음 정보를 포함합니다:

  • 공급자 URL: https://gitlab.com 또는 http://gitlab.example.com과 같은 GitLab 인스턴스 주소. 이 주소는 공개적으로 접근 가능해야 합니다. 공개적으로 접근 불가능한 경우, 공개되지 않은 GitLab 인스턴스 구성 방법을 참조하세요.

  • 대상: 요청된 보안 토큰과 함께 사용하려는 대상 서비스의 논리적 이름.

    • AWS OIDC 통합에서, 이는 일반적으로 IAM OIDC ID 공급자에 구성된 대상 값과 일치합니다(종종 sts.amazonaws.com 또는 GitLab 인스턴스 URL).
    • 이 값은 토큰이 특정 ID 공급자를 위한 것임을 확인하기 위해 AWS에서 검증됩니다.

    [!note] https://gitlab.com 또는 GitLab 인스턴스 URL은 AWS ID 공급자 참조가 일치하는 경우 작동할 수 있지만, 의미상으로는 잘못된 것입니다. 대상은 토큰을 검증하고 수락하는 서비스를 나타내야 합니다.

역할 및 신뢰 구성#

ID 공급자를 생성한 후, GitLab 리소스에 대한 접근을 제한하는 조건과 함께 웹 ID 역할을 구성합니다. 임시 자격 증명은 AWS Security Token Service를 사용하여 얻으므로, Action을 sts:AssumeRoleWithWebIdentity로 설정합니다.

특정 그룹, 프로젝트, 브랜치 또는 태그로 권한 부여를 제한하기 위해 역할에 대한 사용자 지정 신뢰 정책을 만들 수 있습니다. 지원되는 필터링 유형의 전체 목록은 클라우드 서비스에 연결을 참조하세요.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::AWS_ACCOUNT:oidc-provider/gitlab.example.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "gitlab.example.com:sub": "project_path:mygroup/myproject:ref_type:branch:ref:main"
        }
      }
    }
  ]
}

역할이 생성된 후, AWS 서비스(S3, EC2, Secrets Manager)에 대한 권한을 정의하는 정책을 연결합니다.

임시 자격 증명 검색#

OIDC와 역할을 구성한 후, GitLab CI/CD 작업은 AWS Security Token Service(STS)에서 임시 자격 증명을 검색할 수 있습니다.

assume role:
  id_tokens:
    GITLAB_OIDC_TOKEN:
      aud: https://gitlab.example.com
  script:
    # 올바른 종료 코드 처리를 위해 분리됨
    - >
      aws_sts_output=$(aws sts assume-role-with-web-identity
      --role-arn ${ROLE_ARN}
      --role-session-name "GitLabRunner-${CI_PROJECT_ID}-${CI_PIPELINE_ID}"
      --web-identity-token ${GITLAB_OIDC_TOKEN}
      --duration-seconds 3600
      --query 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken]'
      --output text)
    - export $(printf "AWS_ACCESS_KEY_ID=%s AWS_SECRET_ACCESS_KEY=%s AWS_SESSION_TOKEN=%s" $aws_sts_output)
    - aws sts get-caller-identity
  • ROLE_ARN: 이 단계에서 정의된 역할 ARN.
  • GITLAB_OIDC_TOKEN: OIDC ID 토큰.

작동 예시#

공개되지 않은 GitLab 인스턴스 구성#

히스토리
Warning

이 해결 방법은 이해해야 할 보안 고려 사항이 있는 고급 구성 옵션입니다. 개인 GitLab Self-Managed 인스턴스에서 S3 버킷과 같은 공개적으로 사용 가능한 위치로 OpenID 구성 및 공개 키를 올바르게 동기화해야 합니다. 또한 S3 버킷과 내부 파일이 적절히 보안되어 있는지 확인해야 합니다. S3 버킷을 제대로 보안하지 못하면 이 OpenID Connect ID와 연결된 클라우드 계정이 탈취될 수 있습니다.

GitLab 인스턴스에 공개적으로 접근할 수 없는 경우, 기본적으로 AWS에서 OpenID Connect를 구성할 수 없습니다. 일부 특정 구성을 공개적으로 접근 가능하게 만들어 인스턴스에 대한 OpenID Connect 구성을 활성화하는 해결 방법을 사용할 수 있습니다:

  1. 공개적으로 사용 가능한 위치(예: S3 파일)에 GitLab 인스턴스의 인증 세부 정보를 저장합니다:

    • S3 파일에서 인스턴스의 OpenID 구성을 호스팅합니다. 구성은 http://gitlab.example.com/.well-known/openid-configuration과 같이 /.well-known/openid-configuration에서 사용 가능합니다. 공개적으로 사용 가능한 위치를 가리키도록 구성 파일의 issuer: 및 jwks_uri: 값을 업데이트합니다.
    • S3 파일에서 인스턴스 URL의 공개 키를 호스팅합니다. 키는 http://gitlab.example.com/oauth/discovery/keys와 같이 /oauth/discovery/keys에서 사용 가능합니다.

    예시:

    • OpenID 구성 파일: https://example-oidc-configuration-s3-bucket.s3.eu-north-1.amazonaws.com/.well-known/openid-configuration.
    • JWKS(JSON 웹 키 세트): https://example-oidc-configuration-s3-bucket.s3.eu-north-1.amazonaws.com/oauth/discovery/keys.
    • ID 토큰의 발급자 클레임 iss: 및 OpenID 구성의 issuer: 값은 다음과 같습니다: https://example-oidc-configuration-s3-bucket.s3.eu-north-1.amazonaws.com

  2. 선택 사항. OpenID 구성 엔드포인트 유효성 검사기와 같은 OpenID 구성 유효성 검사기를 사용하여 공개적으로 사용 가능한 OpenID 구성의 유효성을 검사합니다.

  3. ID 토큰에 대한 사용자 지정 발급자 클레임을 구성합니다. 기본적으로 GitLab ID 토큰은 발급자 클레임 iss:가 GitLab 인스턴스 주소로 설정됩니다(예: http://gitlab.example.com).

  4. 발급자 URL을 업데이트합니다:

  5. /etc/gitlab/gitlab.rb를 편집합니다:

    gitlab_rails['ci_id_tokens_issuer_url'] = '<public_url_with_openid_configuration_and_keys>'

    <public_url_with_openid_configuration_and_keys>를 https://example-oidc-configuration-s3-bucket.s3.eu-north-1.amazonaws.com과 같은 URL로 교체합니다.

    1. 파일을 저장하고 변경 사항이 적용되도록 GitLab을 재구성합니다.

  1. Helm 값을 내보냅니다:

    helm get values gitlab > gitlab_values.yaml

    1. gitlab_values.yaml을 편집합니다:

      global:
  appConfig:
    ciIdTokens:
      issuerUrl: '<public_url_with_openid_configuration_and_keys>'

      <public_url_with_openid_configuration_and_keys>를 https://example-oidc-configuration-s3-bucket.s3.eu-north-1.amazonaws.com과 같은 URL로 교체합니다.

    2. 파일을 저장하고 새 값을 적용합니다:

      helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab

  1. docker-compose.yml을 편집합니다:

    version: "3.6"
services:
  gitlab:
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        gitlab_rails['ci_id_tokens_issuer_url'] = '<public_url_with_openid_configuration_and_keys>'

    <public_url_with_openid_configuration_and_keys>를 https://example-oidc-configuration-s3-bucket.s3.eu-north-1.amazonaws.com과 같은 URL로 교체합니다.

    1. 파일을 저장하고 GitLab을 재시작합니다:

      docker compose up -d

  1. /home/git/gitlab/config/gitlab.yml을 편집합니다:

     production: &base
   ci_id_tokens:
     issuer_url: '<public_url_with_openid_configuration_and_keys>'

    <public_url_with_openid_configuration_and_keys>를 https://example-oidc-configuration-s3-bucket.s3.eu-north-1.amazonaws.com과 같은 URL로 교체합니다.

    1. 파일을 저장하고 변경 사항이 적용되도록 GitLab을 재구성합니다.
  1. ci:validate_id_token_configuration Rake 태스크를 실행하여 CI/CD ID 토큰 구성의 유효성을 검사합니다.

문제 해결#

오류: Not authorized to perform sts:AssumeRoleWithWebIdentity#

이 오류가 발생하는 경우:

An error occurred (AccessDenied) when calling the AssumeRoleWithWebIdentity operation:
Not authorized to perform sts:AssumeRoleWithWebIdentity

여러 가지 이유로 발생할 수 있습니다:

Could not connect to openid configuration of provider 오류#

AWS IAM에 ID 공급자를 추가한 후 다음 오류가 발생할 수 있습니다:

Your request has a problem. Please see the following details.
  - Could not connect to openid configuration of provider: `https://gitlab.example.com`

이 오류는 OIDC ID 공급자의 발급자가 순서가 잘못되었거나 중복 또는 추가 인증서가 포함된 인증서 체인을 제공할 때 발생합니다.

GitLab 인스턴스의 인증서 체인을 확인합니다. 체인은 도메인 또는 발급자 URL로 시작하여 중간 인증서, 루트 인증서로 끝나야 합니다. 다음 명령을 사용하여 gitlab.example.com을 GitLab 호스트 이름으로 바꿔 인증서 체인을 검토합니다:

echo | /opt/gitlab/embedded/bin/openssl s_client -connect gitlab.example.com:443

Couldn't retrieve verification key from your identity provider 오류#

다음과 유사한 오류가 발생할 수 있습니다:

이 오류의 원인:

이 오류에 대한 AWS Knowledge Center 문서에 문서화된 것처럼 GitLab 인스턴스는 .well_known URL 및 jwks_uri를 확인할 수 있도록 공개적으로 접근 가능해야 합니다. 예를 들어 GitLab 인스턴스가 오프라인 환경에 있는 경우, 공개되지 않은 GitLab 인스턴스 구성 방법을 참조하세요.