인증 및 권한 부여

Red Hat OpenShift Service on AWS 4

AWS 클러스터에서 Red Hat OpenShift Service 보안

Red Hat OpenShift Documentation Team

초록

이 문서에서는 ROSA(Red Hat OpenShift Service on AWS) 클러스터 보안에 대한 정보를 제공합니다.

1장. 서비스 계정에 AWS IAM 역할 가정

AWS STS(보안 토큰 서비스)를 사용하는 AWS 클러스터의 Red Hat OpenShift Service에는 사용자 정의 프로젝트에서 실행되는 Pod와 함께 사용할 수 있는 Pod ID 웹 후크가 포함되어 있습니다.

Pod ID Webhook를 사용하여 서비스 계정에서 자체 Pod에서 AWS IAM(Identity and Access Management) 역할을 자동으로 가정할 수 있습니다. 가정된 IAM 역할에 필요한 AWS 권한이 있는 경우 Pod는 임시 STS 인증 정보를 사용하여 AWS SDK 작업을 실행할 수 있습니다.

1.1. 사용자 정의 프로젝트에서 Pod ID 웹 후크 워크플로 이해

AWS STS(보안 토큰 서비스)를 사용하는 AWS 클러스터에 Red Hat OpenShift Service를 설치하면 Pod ID 웹 후크 리소스가 기본적으로 포함됩니다.

Pod ID Webhook를 사용하여 동일한 프로젝트의 Pod에서 AWS IAM(Identity and Access Management) 역할을 가정하도록 사용자 정의 프로젝트의 서비스 계정을 활성화할 수 있습니다. IAM 역할을 가정하면 Pod의 서비스 계정에서 사용할 임시 STS 인증 정보가 제공됩니다. 추정 역할에 필요한 AWS 권한이 있는 경우 서비스 계정은 Pod에서 AWS SDK 작업을 실행할 수 있습니다.

Pod에 대한 Pod ID 웹 후크를 활성화하려면 프로젝트에서 eks.amazonaws.com/role-arn 주석을 사용하여 서비스 계정을 생성해야 합니다. 주석은 서비스 계정이 가정할 AWS IAM 역할의 ARM(Amazon Resource Name)을 참조해야 합니다. Pod 사양에서 서비스 계정을 참조하고 서비스 계정과 동일한 프로젝트에서 Pod를 배포해야 합니다.

사용자 정의 프로젝트의 Pod ID Webhook 워크플로

다음 다이어그램은 사용자 정의 프로젝트의 Pod ID Webhook 워크플로를 보여줍니다.

그림 1.1. 사용자 정의 프로젝트의 Pod ID Webhook 워크플로

Pod ID Webhook 워크플로

워크플로는 다음 단계가 있습니다.

  1. 사용자 정의 프로젝트에서 사용자는 eks.amazonaws.com/role-arn 주석을 포함하는 서비스 계정을 생성합니다. 주석은 서비스 계정에서 가정할 AWS IAM 역할의 ARN을 가리킵니다.
  2. 주석이 있는 서비스 계정을 참조하는 구성을 사용하여 Pod를 동일한 프로젝트에 배포하면 Pod ID Webhook에서 Pod가 변경됩니다. 이 변경으로 인해 Pod 또는 배포 리소스 구성에서 해당 구성 요소를 지정하지 않고도 다음 구성 요소를 Pod 에 삽입합니다.

    • AWS SDK 작업을 실행하는 데 필요한 권한이 있는 IAM 역할에 대한 ARN이 포함된 $AWS_ARN_ROLE 환경 변수
    • 서비스 계정의 OIDC(Open ID Connect) 토큰에 Pod의 전체 경로가 포함된 $AWS_ please_IDENTITY_TOKEN_FILE 환경 변수입니다. 전체 경로는 /var/run/secrets/eks.amazonaws.com/serviceaccount/token 입니다.
    • 마운트 지점 /var/run/secrets/eks.amazonaws.com/serviceaccount 에 마운트된 aws-iam-token 볼륨. token이라는 OIDC 토큰 파일은 볼륨에 포함되어 있습니다.
  3. OIDC 토큰은 Pod에서 OIDC 공급자로 전달됩니다. 다음 요구 사항이 충족되면 공급자는 서비스 계정 ID를 인증합니다.

    • ID 서명이 유효하고 개인 키로 서명됩니다.
    • sts.amazonaws.com 대상이 OIDC 토큰에 나열되고 OIDC 공급자에 구성된 대상과 일치합니다.

      참고

      Pod ID 웹 후크는 sts.amazonaws.com 대상을 기본적으로 OIDC 토큰에 적용합니다.

      STS 클러스터가 있는 AWS의 Red Hat OpenShift Service에서 설치 중에 OIDC 공급자가 생성되고 기본적으로 서비스 계정 발행자로 설정됩니다. sts.amazonaws.com 대상은 기본적으로 OIDC 공급자에 설정됩니다.

    • OIDC 토큰이 만료되지 않았습니다.
    • 토큰의 발행자 값에는 OIDC 공급자의 URL이 포함되어 있습니다.
  4. 프로젝트 및 서비스 계정이 가정 중인 IAM 역할에 대한 신뢰 정책 범위에 있는 경우 권한 부여가 성공합니다.
  5. 인증 및 권한 부여가 성공하면 세션 토큰 형식의 임시 AWS STS 인증 정보가 서비스 계정에서 사용할 수 있도록 Pod로 전달됩니다. 인증 정보를 사용하면 서비스 계정에 IAM 역할에서 활성화된 AWS 권한이 일시적으로 부여됩니다.
  6. Pod에서 AWS SDK 작업을 실행할 때 서비스 계정은 임시 STS 인증 정보를 AWS API에 제공하여 ID를 확인합니다.

1.2. 자체 Pod에서 AWS IAM 역할을 가정

이 섹션의 절차에 따라 서비스 계정이 사용자 정의 프로젝트에 배포된 Pod에서 AWS IAM(Identity and Access Management) 역할을 가정할 수 있습니다.

AWS IAM 역할, 서비스 계정, AWS SDK가 포함된 컨테이너 이미지 및 이미지를 사용하여 배포한 Pod를 포함하여 필요한 리소스를 생성할 수 있습니다. 이 예제에서는 AWS Boto3 SDK for Python이 사용됩니다. Pod ID Webhook에서 AWS 환경 변수, 볼륨 마운트 및 토큰 볼륨을 Pod에 변경하는지 확인할 수도 있습니다. 또한 서비스 계정이 Pod에서 AWS IAM 역할을 가정하고 AWS SDK 작업을 성공적으로 실행할 수 있는지 확인할 수 있습니다.

1.2.1. 서비스 계정에 AWS IAM 역할 설정

AWS 클러스터의 Red Hat OpenShift Service의 서비스 계정으로 간주할 AWS Identity and Access Management(IAM) 역할을 생성합니다. 서비스 계정에 필요한 권한을 연결하여 Pod에서 AWS SDK 작업을 실행합니다.

사전 요구 사항

  • AWS 계정에 IAM 역할을 설치하고 구성하는 데 필요한 권한이 있습니다.
  • AWS STS(보안 토큰 서비스)를 사용하는 AWS 클러스터의 Red Hat OpenShift Service에 액세스할 수 있습니다. 관리자 수준 사용자 권한이 필요하지 않습니다.
  • STS 클러스터가 있는 AWS의 Red Hat OpenShift Service에 서비스 계정 발행자로 구성된 OIDC(OpenID Connect) 공급자의 ARM(Amazon Resource Name)이 있습니다.

    참고

    STS 클러스터가 있는 AWS의 Red Hat OpenShift Service에서 설치 중에 OIDC 공급자가 생성되고 기본적으로 서비스 계정 발행자로 설정됩니다. OIDC 공급자 ARN을 모르는 경우 클러스터 관리자에게 문의하십시오.

  • AWS CLI(aws)가 설치되어 있습니다.

절차

  1. 다음 JSON 구성을 사용하여 trust-policy.json 이라는 파일을 생성합니다.

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Principal": {
                    "Federated": "<oidc_provider_arn>" 1
                },
                "Action": "sts:AssumeRoleWithWebIdentity",
                "Condition": {
                    "StringEquals": {
                        "<oidc_provider_name>:sub": "system:serviceaccount:<project_name>:<service_account_name>" 2
                    }
                }
            }
        ]
    }
    1
    < oidc_provider_arn >을 OIDC 공급자의 ARN으로 바꿉니다(예 : arn:aws::<aws_account_id>:oidc-provider/rh-oidc.s3.us-east-1.amazonaws.com/1v3r0n44npxu4g46aeohduomfres ).
    2
    지정된 프로젝트 및 서비스 계정에 역할을 제한합니다. < oidc_provider_name >을 OIDC 공급자의 이름으로 교체합니다(예: rh-oidc.s3.us-east-1.amazonaws.com/1v3r0n44n44u4g58so46aeohduomfres ). < project_name>:<service_account_name >을 프로젝트 이름 및 서비스 계정 이름으로 교체합니다(예: my-project:test-service-account ).
    참고

    또는 "< oidc_provider_name>:sub": "system:serviceaccount:<project_name>:*"을 사용하여 지정된 프로젝트 내의 모든 서비스 계정으로 역할을 제한할 수 있습니다. * 와일드카드를 제공하는 경우 StringEquals 를 이전 줄에서 StringLike 로 교체해야 합니다.

  2. trust-policy.json 파일에 정의된 신뢰 정책을 사용하는 AWS IAM 역할을 생성합니다.

    $ aws iam create-role \
        --role-name <aws_iam_role_name> \ 1
        --assume-role-policy-document file://trust-policy.json 2
    1
    & lt;aws_iam_role_name >을 IAM 역할의 이름으로 교체합니다(예: pod-identity-test-role ).
    2
    이전 단계에서 생성한 trust-policy.json 파일을 참조합니다.

    출력 예:

    ROLE    arn:aws:iam::<aws_account_id>:role/<aws_iam_role_name>        2022-09-28T12:03:17+00:00       /       AQWMS3TB4Z2N3SH7675JK   <aws_iam_role_name>
    ASSUMEROLEPOLICYDOCUMENT        2012-10-17
    STATEMENT       sts:AssumeRoleWithWebIdentity   Allow
    STRINGEQUALS    system:serviceaccount:<project_name>:<service_account_name>
    PRINCIPAL       <oidc_provider_arn>

    출력에서 역할의 ARN을 유지합니다. 역할 ARN 형식은 arn:aws:iam::<aws_account_id>:role/<aws_iam_role_name >입니다.

  3. 서비스 계정이 Pod에서 AWS SDK 작업을 실행할 때 필요한 관리형 AWS 권한을 연결합니다.

    $ aws iam attach-role-policy \
        --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess \ 1
        --role-name <aws_iam_role_name> 2
    1
    이 예제의 정책은 IAM 역할에 읽기 전용 액세스 권한을 추가합니다.
    2
    & lt;aws_iam_role_name >을 이전 단계에서 생성한 IAM 역할의 이름으로 교체합니다.
  4. 선택 사항: 사용자 지정 특성 또는 권한 경계를 역할에 추가합니다. 자세한 내용은 AWS 문서의 AWS 서비스에 권한을 위임하는 역할 생성을 참조하십시오.

1.2.2. 프로젝트에서 서비스 계정 생성

사용자 정의 프로젝트에 서비스 계정을 추가합니다. 서비스 계정에서 가정할 AWS ID 및 액세스 관리(IAM) 역할의 ARM(Amazon Resource Name)을 참조하는 서비스 계정 구성에 eks.amazonaws.com/role-arn 주석을 포함합니다.

사전 요구 사항

  • 서비스 계정에 대한 AWS IAM 역할을 생성했습니다. 자세한 내용은 서비스 계정에 대한 AWS IAM 역할 설정을 참조하십시오.
  • AWS STS(Security Token Service) 클러스터가 있는 AWS의 Red Hat OpenShift Service에 액세스할 수 있습니다. 관리자 수준 사용자 권한이 필요하지 않습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.

절차

  1. Red Hat OpenShift Service on AWS 클러스터에서 프로젝트를 생성합니다.

    $ oc new-project <project_name> 1
    1
    & lt;project_name >을 프로젝트 이름으로 바꿉니다. 이름은 AWS IAM 역할 구성에 지정한 프로젝트 이름과 일치해야 합니다.
    참고

    프로젝트가 생성되면 자동으로 프로젝트로 전환됩니다.

  2. 다음 서비스 계정 구성을 사용하여 test-service-account.yaml 이라는 파일을 생성합니다.

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: <service_account_name> 1
      namespace: <project_name> 2
      annotations:
        eks.amazonaws.com/role-arn: "<aws_iam_role_arn>" 3
    1
    & lt;service_account_name >을 서비스 계정 이름으로 바꿉니다. 이름은 AWS IAM 역할 구성에 지정한 서비스 계정 이름과 일치해야 합니다.
    2
    & lt;project_name >을 프로젝트 이름으로 바꿉니다. 이름은 AWS IAM 역할 구성에 지정한 프로젝트 이름과 일치해야 합니다.
    3
    서비스 계정이 Pod 내에서 사용하기 위해 가정하는 AWS IAM 역할의 ARN을 지정합니다. & lt;aws_iam_role_arn >을 서비스 계정에 대해 생성한 AWS IAM 역할의 ARN으로 바꿉니다. 역할 ARN 형식은 arn:aws:iam::<aws_account_id>:role/<aws_iam_role_name >입니다.
  3. 프로젝트에서 서비스 계정을 생성합니다.

    $ oc create -f test-service-account.yaml

    출력 예:

    serviceaccount/<service_account_name> created

  4. 서비스 계정의 세부 정보를 검토합니다.

    $ oc describe serviceaccount <service_account_name> 1
    1
    & lt;service_account_name >을 서비스 계정 이름으로 바꿉니다.

    출력 예:

    Name:                <service_account_name> 1
    Namespace:           <project_name> 2
    Labels:              <none>
    Annotations:         eks.amazonaws.com/role-arn: <aws_iam_role_arn> 3
    Image pull secrets:  <service_account_name>-dockercfg-rnjkq
    Mountable secrets:   <service_account_name>-dockercfg-rnjkq
    Tokens:              <service_account_name>-token-4gbjp
    Events:              <none>

    1
    서비스 계정의 이름을 지정합니다.
    2
    서비스 계정이 포함된 프로젝트를 지정합니다.
    3
    서비스 계정이 가정하는 AWS IAM 역할의 ARN에 대한 주석을 나열합니다.

1.2.3. AWS SDK 컨테이너 이미지 예제 생성

이 절차의 단계에서는 AWS SDK를 포함하는 컨테이너 이미지를 생성하는 예제 방법을 제공합니다.

예제 단계에서는 Podman을 사용하여 이미지를 호스팅할 컨테이너 이미지와 Quay.io를 생성합니다. Quay.io에 대한 자세한 내용은 Quay.io 시작하기를 참조하십시오. 컨테이너 이미지는 AWS SDK 작업을 실행할 수 있는 Pod를 배포하는 데 사용할 수 있습니다.

참고

이 예제 절차에서는 AWS Boto3 SDK for Python이 컨테이너 이미지에 설치됩니다. AWS Boto3 SDK 설치 및 사용에 대한 자세한 내용은 AWS Boto3 설명서를 참조하십시오. 다른 AWS SDK에 대한 자세한 내용은 AWS 문서의 AWS SDK 및 툴 참조 가이드를 참조하십시오.

사전 요구 사항

  • 설치 호스트에 Podman을 설치했습니다.
  • Quay.io 사용자 계정이 있습니다.

절차

  1. Containerfile 이라는 파일에 다음 구성을 추가합니다.

    FROM ubi9/ubi 1
    RUN dnf makecache && dnf install -y python3-pip && dnf clean all && pip3 install boto3>=1.15.0 2
    1
    Red Hat Universal Base Image 버전 9를 지정합니다.
    2
    pip 패키지 관리 시스템을 사용하여 AWS Boto3 SDK를 설치합니다. 이 예에서는 AWS Boto3 SDK 버전 1.15.0 이상이 설치되어 있습니다.
  2. 파일이 포함된 디렉터리에서 awsboto3sdk 라는 컨테이너 이미지를 빌드합니다.

    $ podman build -t awsboto3sdk .
  3. Quay.io에 로그인합니다.

    $ podman login quay.io
  4. Quay.io에 업로드할 준비를 위해 이미지에 태그를 지정합니다.

    $ podman tag localhost/awsboto3sdk quay.io/<quay_username>/awsboto3sdk:latest 1
    1
    &lt ;quay_username&gt;을 Quay.io 사용자 이름으로 교체합니다.
  5. 태그된 컨테이너 이미지를 Quay.io로 푸시합니다.

    $ podman push quay.io/<quay_username>/awsboto3sdk:latest 1
    1
    &lt ;quay_username&gt;을 Quay.io 사용자 이름으로 교체합니다.
  6. 이미지가 public으로 포함된 Quay.io 리포지토리를 만듭니다. 이렇게 하면 AWS 클러스터에 Red Hat OpenShift Service에 Pod를 배포하는 데 사용할 수 있는 이미지가 게시됩니다.

    1. https://quay.io/ 에서 이미지가 포함된 리포지토리의 리포지토리 설정 페이지로 이동합니다.
    2. Make Public 을 클릭하여 리포지토리를 공개하도록 합니다.

1.2.4. AWS SDK를 포함하는 Pod 배포

AWS SDK가 포함된 컨테이너 이미지에서 사용자 정의 프로젝트에 Pod를 배포합니다. Pod 구성에서 eks.amazonaws.com/role-arn 주석이 포함된 서비스 계정을 지정합니다.

Pod에 대한 서비스 계정 참조를 사용하면 Pod ID Webhook에서 AWS 환경 변수, 볼륨 마운트 및 토큰 볼륨을 Pod에 삽입합니다. Pod 변경을 사용하면 서비스 계정에서 Pod에서 AWS IAM 역할을 자동으로 가정할 수 있습니다.

사전 요구 사항

  • 서비스 계정에 대한 AWS IAM(Identity and Access Management) 역할이 생성되어 있습니다. 자세한 내용은 서비스 계정에 대한 AWS IAM 역할 설정을 참조하십시오.
  • AWS STS(보안 토큰 서비스)를 사용하는 AWS 클러스터의 Red Hat OpenShift Service에 액세스할 수 있습니다. 관리자 수준 사용자 권한이 필요하지 않습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
  • 서비스 계정에서 가정할 IAM 역할에 대한 Amazon Resource Name(ARN)을 참조하는 eks.amazonaws.com/role-arn 주석이 포함된 프로젝트에 서비스 계정을 생성했습니다.
  • AWS SDK가 포함된 컨테이너 이미지가 있고 해당 이미지를 클러스터에서 사용할 수 있습니다. 자세한 단계는 AWS SDK 컨테이너 이미지 예제를 참조하십시오.

    참고

    이 예제 절차에서는 AWS Boto3 SDK for Python을 사용합니다. AWS Boto3 SDK 설치 및 사용에 대한 자세한 내용은 AWS Boto3 설명서를 참조하십시오. 다른 AWS SDK에 대한 자세한 내용은 AWS 문서의 AWS SDK 및 툴 참조 가이드를 참조하십시오.

절차

  1. 다음 Pod 구성을 사용하여 awsboto3sdk-pod.yaml 이라는 파일을 생성합니다.

    apiVersion: v1
    kind: Pod
    metadata:
      namespace: <project_name> 1
      name: awsboto3sdk 2
    spec:
      serviceAccountName: <service_account_name> 3
      containers:
      - name: awsboto3sdk
        image: quay.io/<quay_username>/awsboto3sdk:latest 4
        command:
        - /bin/bash
        - "-c"
        - "sleep 100000" 5
      terminationGracePeriodSeconds: 0
      restartPolicy: Never
    1
    & lt;project_name >을 프로젝트 이름으로 바꿉니다. 이름은 AWS IAM 역할 구성에 지정한 프로젝트 이름과 일치해야 합니다.
    2
    pod 이름을 지정합니다.
    3
    & lt;service_account_name >을 AWS IAM 역할을 가정하도록 구성된 서비스 계정 이름으로 교체합니다. 이름은 AWS IAM 역할 구성에 지정한 서비스 계정 이름과 일치해야 합니다.
    4
    awsboto3sdk 컨테이너 이미지의 위치를 지정합니다. &lt ;quay_username&gt;을 Quay.io 사용자 이름으로 교체합니다.
    5
    이 예제 Pod 구성에서는 이 줄에서 100000초 동안 Pod를 실행하여 Pod에서 직접 검증 테스트를 수행할 수 있습니다. 자세한 확인 단계는 Pod에서 가정된 IAM 역할 확인을 참조하십시오.
  2. awsboto3sdk Pod를 배포합니다.

    $ oc create -f awsboto3sdk-pod.yaml

    출력 예:

    pod/awsboto3sdk created

1.2.5. Pod에서 가정된 IAM 역할 확인

프로젝트에 awsboto3sdk Pod를 배포한 후 Pod ID Webhook에서 Pod를 변경했는지 확인합니다. 필요한 AWS 환경 변수, 볼륨 마운트 및 OIDC 토큰 볼륨이 Pod 내에 있는지 확인합니다.

Pod에서 AWS SDK 작업을 실행할 때 서비스 계정이 AWS 계정에 대해 IAM(Identity and Access Management) 역할을 가정하는지 확인할 수도 있습니다.

사전 요구 사항

  • 서비스 계정에 대한 AWS IAM 역할을 생성했습니다. 자세한 내용은 서비스 계정에 대한 AWS IAM 역할 설정을 참조하십시오.
  • AWS STS(보안 토큰 서비스)를 사용하는 AWS 클러스터의 Red Hat OpenShift Service에 액세스할 수 있습니다. 관리자 수준 사용자 권한이 필요하지 않습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
  • 서비스 계정에서 가정할 IAM 역할에 대한 Amazon Resource Name(ARN)을 참조하는 eks.amazonaws.com/role-arn 주석이 포함된 프로젝트에 서비스 계정을 생성했습니다.
  • AWS SDK가 포함된 사용자 정의 프로젝트에 Pod를 배포했습니다. Pod는 Pod ID Webhook를 사용하여 AWS SDK 작업을 실행하는 데 필요한 AWS IAM 역할을 가정하는 서비스 계정을 참조합니다. 자세한 단계는 AWS SDK가 포함된 Pod 배포를 참조하십시오.

    참고

    이 예제 절차에서는 AWS Boto3 SDK for Python을 포함하는 Pod를 사용합니다. AWS Boto3 SDK 설치 및 사용에 대한 자세한 내용은 AWS Boto3 설명서를 참조하십시오. 다른 AWS SDK에 대한 자세한 내용은 AWS 문서의 AWS SDK 및 툴 참조 가이드를 참조하십시오.

절차

  1. AWS 환경 변수, 볼륨 마운트 및 OIDC 토큰 볼륨이 배포된 awsboto3sdk Pod 설명에 나열되어 있는지 확인합니다.

    $ oc describe pod awsboto3sdk

    출력 예:

    Name:         awsboto3sdk
    Namespace:    <project_name>
    ...
    Containers:
      awsboto3sdk:
        ...
        Environment:
          AWS_ROLE_ARN:                 <aws_iam_role_arn> 1
          AWS_WEB_IDENTITY_TOKEN_FILE:  /var/run/secrets/eks.amazonaws.com/serviceaccount/token 2
        Mounts:
          /var/run/secrets/eks.amazonaws.com/serviceaccount from aws-iam-token (ro) 3
    ...
    Volumes:
      aws-iam-token: 4
        Type:                    Projected (a volume that contains injected data from multiple sources)
        TokenExpirationSeconds:  86400
    ...

    1
    Pod ID Webhook에서 Pod에 삽입한 AWS_ROLE_ARN 환경 변수를 나열합니다. 변수에는 서비스 계정에서 가정하는 AWS IAM 역할의 ARN이 포함되어 있습니다.
    2
    Pod ID Webhook에서 Pod에 삽입한 AWS__IDENTITY_TOKEN_FILE 환경 변수를 나열합니다. 변수에는 서비스 계정 ID를 확인하는 데 사용되는 OIDC 토큰의 전체 경로가 포함됩니다.
    3
    Pod ID 웹 후크를 통해 Pod에 삽입된 볼륨 마운트를 나열합니다.
    4
    /var/run/secrets/eks.amazonaws.com/serviceaccount 마운트 지점에 마운트된 aws-iam-token 볼륨을 나열합니다. 볼륨에는 AWS IAM 역할을 가정하기 위해 서비스 계정을 인증하는 데 사용되는 OIDC 토큰이 포함되어 있습니다.
  2. awsboto3sdk Pod에서 대화형 터미널을 시작합니다.

    $ oc exec -ti awsboto3sdk -- /bin/sh
  3. Pod의 대화형 터미널에서 Pod ID 웹 후크에 의해 $AWS_ROLE_ARN 환경 변수가 Pod로 변경되었는지 확인합니다.

    $ echo $AWS_ROLE_ARN

    출력 예:

    arn:aws:iam::<aws_account_id>:role/<aws_iam_role_name> 1

    1
    출력은 AWS SDK 작업을 실행하는 데 필요한 권한이 있는 AWS IAM 역할의 ARN을 지정해야 합니다.
  4. Pod의 대화형 터미널에서 $AWS_ please_IDENTITY_TOKEN_FILE 환경 변수가 Pod ID 웹 후크에 의해 Pod로 변경되었는지 확인합니다.

    $ echo $AWS_WEB_IDENTITY_TOKEN_FILE

    출력 예:

    /var/run/secrets/eks.amazonaws.com/serviceaccount/token 1

    1
    출력은 서비스 계정의 OIDC 토큰까지 Pod의 전체 경로를 지정해야 합니다.
  5. Pod의 대화형 터미널에서 OIDC 토큰 파일을 포함하는 aws-iam-token 볼륨 마운트가 Pod ID 웹 후크에 의해 마운트되었는지 확인합니다.

    $ mount | grep -is 'eks.amazonaws.com'

    출력 예:

    tmpfs on /run/secrets/eks.amazonaws.com/serviceaccount type tmpfs (ro,relatime,seclabel,size=13376888k)

  6. Pod의 대화형 터미널에서 token 이라는 OIDC 토큰 파일이 /var/run/secrets/eks.amazonaws.com/serviceaccount/ 마운트 지점에 있는지 확인합니다.

    $ ls /var/run/secrets/eks.amazonaws.com/serviceaccount/token

    출력 예:

    /var/run/secrets/eks.amazonaws.com/serviceaccount/token 1

    1
    Pod ID 웹 후크에 의해 Pod에 마운트된 aws-iam-token 볼륨의 OIDC 토큰 파일입니다. 토큰은 AWS에서 서비스 계정의 ID를 인증하는 데 사용됩니다.
  7. Pod에서 AWS Boto3 SDK 작업이 성공적으로 실행되는지 확인합니다.

    1. Pod의 대화형 터미널에서 Python 3 쉘을 시작합니다.

      $ python3
    2. Python 3 쉘에서 boto3 모듈을 가져옵니다.

      >>> import boto3
    3. Boto3 s3 서비스 리소스를 포함하는 변수를 생성합니다.

      >>> s3 = boto3.resource('s3')
    4. AWS 계정에 있는 모든 S3 버킷의 이름을 출력합니다.

      >>> for bucket in s3.buckets.all():
      ...     print(bucket.name)
      ...

      출력 예:

      <bucket_name>
      <bucket_name>
      <bucket_name>
      ...

      서비스 계정이 AWS IAM 역할로 가정하면 출력에 AWS 계정에서 사용할 수 있는 모든 S3 버킷이 나열됩니다.

1.3. 추가 리소스

2장. 보안 컨텍스트 제약 조건 관리

AWS의 Red Hat OpenShift Service에서는 SCC(보안 컨텍스트 제약 조건)를 사용하여 클러스터의 Pod에 대한 권한을 제어할 수 있습니다.

기본 SCC는 설치 중에 생성되며 일부 Operator 또는 기타 구성 요소를 설치할 때 생성됩니다. 클러스터 관리자는 OpenShift CLI(oc)를 사용하여 자체 SCC를 생성할 수도 있습니다.

중요

기본 SCC를 수정하지 마십시오. 기본 SCC를 사용자 정의하면 일부 플랫폼 Pod가 배포되거나 ROSA가 업그레이드될 때 문제가 발생할 수 있습니다. 또한 일부 클러스터 업그레이드 중에 기본 SCC 값이 기본값으로 재설정되므로 해당 SCC에 대한 모든 사용자 정의가 삭제됩니다.

기본 SCC를 수정하는 대신 필요에 따라 자체 SCC를 생성하고 수정합니다. 자세한 단계는 보안 컨텍스트 제약 조건 생성을 참조하십시오.

2.1. 보안 컨텍스트 제약 조건 정보

RBAC 리소스에서 사용자 액세스 권한을 제어하는 방식과 유사하게 관리자는 SCC(보안 컨텍스트 제약 조건)를 사용하여 Pod에 대한 권한을 제어할 수 있습니다. 이러한 권한은 Pod에서 수행할 수 있는 작업과 액세스할 수 있는 리소스를 결정합니다. Pod가 시스템에 수용되려면 일련의 조건을 함께 실행해야 하는데, SCC를 사용하여 이러한 조건을 정의할 수 있습니다.

시크릿 컨텍스트 제약 조건을 통해 관리자는 다음을 제어할 수 있습니다.

  • Pod에서 allowPrivilegedContainer 플래그를 사용하여 권한 있는 컨테이너를 실행할 수 있는지 여부
  • allowPrivilegeEscalation 플래그로 Pod 제한 여부
  • 컨테이너에서 요청할 수 있는 기능
  • 호스트 디렉터리를 볼륨으로 사용
  • 컨테이너의 SELinux 컨텍스트
  • 컨테이너 사용자 ID
  • 호스트 네임스페이스 및 네트워킹 사용
  • Pod 볼륨을 보유한 FSGroup의 할당
  • 허용되는 추가 그룹의 구성
  • 컨테이너에 루트 파일 시스템에 대한 쓰기 액세스 권한이 필요한지 여부
  • 볼륨 유형 사용
  • 허용 가능한 seccomp 프로필 구성
중요

AWS의 Red Hat OpenShift Service의 네임스페이스에 openshift.io/run-level 레이블을 설정하지 마십시오. 이 레이블은 내부 Red Hat OpenShift Service on AWS 구성 요소에서 Kubernetes API 서버 및 OpenShift API 서버와 같은 주요 API 그룹의 시작을 관리하기 위해 사용됩니다. openshift.io/run-level 레이블이 설정된 경우 해당 네임스페이스의 Pod에 SCC가 적용되지 않으므로 해당 네임스페이스에서 실행되는 모든 워크로드에 높은 권한이 부여됩니다.

2.1.1. 기본 보안 컨텍스트 제약 조건

아래 표에 설명된 대로 클러스터에는 몇 가지 기본 SCC(보안 컨텍스트 제약 조건)가 포함되어 있습니다. AWS의 Red Hat OpenShift Service에 Operator 또는 기타 구성 요소를 설치할 때 추가 SCC가 설치될 수 있습니다.

중요

기본 SCC를 수정하지 마십시오. 기본 SCC를 사용자 정의하면 일부 플랫폼 Pod가 배포되거나 ROSA가 업그레이드될 때 문제가 발생할 수 있습니다. 또한 일부 클러스터 업그레이드 중에 기본 SCC 값이 기본값으로 재설정되므로 해당 SCC에 대한 모든 사용자 정의가 삭제됩니다.

기본 SCC를 수정하는 대신 필요에 따라 자체 SCC를 생성하고 수정합니다. 자세한 단계는 보안 컨텍스트 제약 조건 생성을 참조하십시오.

표 2.1. 기본 보안 컨텍스트 제약 조건

보안 컨텍스트 제약 조건설명

anyuid

restricted SCC의 모든 기능을 제공하지만 사용자는 모든 UID 및 GID로 실행할 수 있습니다.

hostaccess

모든 호스트 네임스페이스에 액세스할 수 있지만 네임스페이스에 할당된 UID 및 SELinux 컨텍스트를 사용하여 pod를 실행해야 합니다.

주의

이 SCC를 사용하면 네임스페이스, 파일 시스템 및 PID에 대한 호스트 액세스를 허용합니다. 신뢰할 수 있는 pod에서만 사용해야 합니다. 주의해서 실행합니다.

hostmount-anyuid

restricted SCC의 모든 기능을 제공하지만 호스트는 시스템의 모든 UID 및 GID로 마운트하고 실행할 수 있습니다.

주의

이 SCC를 사용하면 UID 0을 포함하여 모든 UID로 호스트 파일 시스템에 액세스할 수 있습니다. 주의해서 실행합니다.

hostnetwork

호스트 네트워킹 및 호스트 포트를 사용할 수 있지만 네임스페이스에 할당된 UID 및 SELinux 컨텍스트로 pod를 실행해야 합니다.

주의

컨트롤 플레인 호스트에서 추가 워크로드가 실행되는 경우 hostnetwork에 대한 액세스를 제공할 때 주의하십시오. 컨트롤 플레인 호스트에서 hostnetwork를 실행하는 워크로드는 클러스터에 효과적으로 루팅되므로 신뢰해야 합니다.

hostnetwork-v2

hostnetwork SCC와 유사하지만 다음과 같은 차이점이 있습니다.

  • ALL 기능은 컨테이너에서 삭제됩니다.
  • NET_BIND_SERVICE 기능을 명시적으로 추가할 수 있습니다.
  • seccompProfile 은 기본적으로 runtime/default 로 설정됩니다.
  • 보안 컨텍스트에서 allowPrivilegeEscalation을 설정하지 않거나 false로 설정해야 합니다.

node-exporter

Prometheus 노드 내보내기에 사용됩니다.

주의

이 SCC를 사용하면 UID 0을 포함하여 모든 UID로 호스트 파일 시스템에 액세스할 수 있습니다. 주의해서 실행합니다.

nonroot

restricted SCC의 모든 기능을 제공하지만 사용자는 루트 이외의 UID로 실행할 수 있습니다. 사용자는 UID를 지정하거나 컨테이너 런타임의 매니페스트에 지정해야 합니다.

nonroot-v2

루트가 아닌 SCC와 유사하지만 다음과 같은 차이점이 있습니다.

  • ALL 기능은 컨테이너에서 삭제됩니다.
  • NET_BIND_SERVICE 기능을 명시적으로 추가할 수 있습니다.
  • seccompProfile 은 기본적으로 runtime/default 로 설정됩니다.
  • 보안 컨텍스트에서 allowPrivilegeEscalation을 설정하지 않거나 false로 설정해야 합니다.

privileged

모든 권한 및 호스트 기능에 대한 액세스를 허용하고 모든 사용자, 그룹, FSGroup 및 모든 SELinux 컨텍스트로 실행할 수 있습니다.

주의

이는 가장 완화된 SCC이며 클러스터 관리에만 사용해야 합니다. 주의해서 실행합니다.

권한 있는 SCC를 사용하면 다음을 수행할 수 있습니다.

  • 사용자가 권한 있는 Pod 실행
  • Pod에서 호스트 디렉터리를 볼륨으로 마운트
  • Pod를 모든 사용자로 실행
  • Pod를 모든 MCS 라벨로 실행
  • Pod에서 호스트의 IPC 네임스페이스 사용
  • Pod에서 호스트의 PID 네임스페이스 사용
  • Pod에서 모든 FSGroup 사용
  • Pod에서 추가 그룹 사용
  • Pod에서 seccomp 프로필 사용
  • Pod에서 모든 기능 요청
참고

Pod 사양에서 privileged: true 설정은 권한 있는 SCC를 반드시 선택하지는 않습니다. 사용자에게 사용할 권한이 있는 경우 PrivilegedContainer: true 가 허용되고 우선 순위가 가장 높은 SCC가 선택됩니다.

restricted

모든 호스트 기능에 대한 액세스를 거부하고 네임스페이스에 할당된 UID 및 SELinux 컨텍스트로 Pod를 실행해야 합니다.

제한된 SCC의 경우 다음을 수행합니다.

  • Pod가 권한에 따라 실행되지 않도록 합니다.
  • Pod에서 호스트 디렉터리 볼륨을 마운트할 수 없는지 확인합니다.
  • 미리 할당된 UID 범위에서 Pod를 사용자로 실행해야 합니다.
  • Pod를 사전 할당된 MCS 라벨로 실행해야 합니다.
  • Pod에서 FSGroup을 사용하도록 허용
  • Pod에서 추가 그룹을 사용하도록 허용

AWS 4.10 또는 이전 버전에서 Red Hat OpenShift Service에서 업그레이드된 클러스터에서는 인증된 사용자가 이 SCC를 사용할 수 있습니다. 액세스 권한이 명시적으로 부여되지 않는 한 제한된 SCC는 AWS 4.11 이상의 새로운 Red Hat OpenShift Service 사용자에게 더 이상 제공되지 않습니다.

restricted-v2

제한된 SCC와 유사하지만 다음과 같은 차이점이 있습니다.

  • ALL 기능은 컨테이너에서 삭제됩니다.
  • NET_BIND_SERVICE 기능을 명시적으로 추가할 수 있습니다.
  • seccompProfile 은 기본적으로 runtime/default 로 설정됩니다.
  • 보안 컨텍스트에서 allowPrivilegeEscalation을 설정하지 않거나 false로 설정해야 합니다.

이는 새 설치에서 제공하는 가장 제한적인 SCC이며 인증된 사용자에게 기본적으로 사용됩니다.

참고

restricted-v2 SCC는 기본적으로 시스템에 포함된 SCC의 가장 제한적입니다. 그러나 보다 제한적인 사용자 정의 SCC를 생성할 수 있습니다. 예를 들어 readOnlyRootFilesystemtrue 로 제한하는 SCC를 생성할 수 있습니다.

2.1.2. 보안 컨텍스트 제약 조건 설정

SCC(보안 컨텍스트 제약 조건)는 pod에서 액세스할 수 있는 보안 기능을 제어하는 설정 및 전략으로 구성됩니다. 이 설정은 세 가지 범주로 분류됩니다.

카테고리설명

부울로 제어

이 유형의 필드는 기본적으로 가장 제한적인 값으로 설정됩니다. 예를 들어, AllowPrivilegedContainer는 값이 지정되지 않은 경우 항상 false로 설정됩니다.

허용 가능한 설정으로 제어

이 유형의 필드는 해당 값이 허용되는지 확인하기 위해 설정과 대조됩니다.

전략으로 제어

가치를 생성하는 전략이 있는 항목에서는 다음을 제공합니다.

  • 가치를 생성하는 메커니즘
  • 지정된 값이 허용된 값 집합에 속하도록 하는 메커니즘

CRI-O에는 Pod의 각 컨테이너에 허용되는 다음 기본 기능 목록이 있습니다.

  • CHOWN
  • DAC_OVERRIDE
  • FSETID
  • FOWNER
  • SETGID
  • SETUID
  • SETPCAP
  • NET_BIND_SERVICE
  • KILL

컨테이너에서는 이 기본 목록의 기능을 사용하지만 Pod 매니페스트 작성자는 추가 기능을 요청하거나 일부 기본 동작을 제거하여 목록을 변경할 수 있습니다. allowedCapabilities,defaultAddCapabilitiesrequiredDropCapabilities 매개변수를 사용하여 Pod에서 이러한 요청을 제어합니다. 이러한 매개변수를 사용하면 요청할 수 있는 기능, 각 컨테이너에 추가해야 하는 기능 및 각 컨테이너에서 금지 또는 삭제해야 하는 기능을 지정할 수 있습니다.

참고

requiredDropCapabilities 매개변수를 ALL 로 설정하여 컨테이너에서 모든 용량을 삭제할 수 있습니다. 이는 restricted-v2 SCC에서 수행하는 작업입니다.

2.1.3. 보안 컨텍스트 제약 조건 전략

RunAsUser

  • MustRunAs - runAsUser를 구성해야 합니다. 구성된 runAsUser를 기본값으로 사용합니다. 구성된 runAsUser에 대해 검증합니다.

    MustRunAs 스니펫 예

    ...
    runAsUser:
      type: MustRunAs
      uid: <id>
    ...

  • MustRunAsRange - 사전 할당된 값을 사용하지 않는 경우 최솟값과 최댓값을 정의해야 합니다. 최솟값을 기본값으로 사용합니다. 전체 허용 범위에 대해 검증합니다.

    MustRunAsRange 스니펫 예

    ...
    runAsUser:
      type: MustRunAsRange
      uidRangeMax: <maxvalue>
      uidRangeMin: <minvalue>
    ...

  • MustRunAsNonRoot - Pod를 0이 아닌 runAsUser를 사용하여 제출하거나 Pod의 이미지에 USER 지시문이 정의되어 있어야 합니다. 기본값이 제공되지 않습니다.

    MustRunAsNonRoot 의 예

    ...
    runAsUser:
      type: MustRunAsNonRoot
    ...

  • RunAsAny - 기본값이 제공되지 않습니다. 모든 runAsUser를 지정할 수 있습니다.

    RunAsAny 스니펫 예

    ...
    runAsUser:
      type: RunAsAny
    ...

SELinuxContext

  • MustRunAs - 사전 할당된 값을 사용하지 않는 경우 seLinuxOptions를 구성해야 합니다. seLinuxOptions를 기본값으로 사용합니다. seLinuxOptions에 대해 검증합니다.
  • RunAsAny - 기본값이 제공되지 않습니다. 모든 seLinuxOptions를 지정할 수 있습니다.

SupplementalGroups

  • MustRunAs - 사전 할당된 값을 사용하지 않는 경우 범위를 하나 이상 지정해야 합니다. 첫 번째 범위의 최솟값을 기본값으로 사용합니다. 모든 범위에 대해 검증합니다.
  • RunAsAny - 기본값이 제공되지 않습니다. 임의의 supplementalGroups을 지정할 수 있습니다.

FSGroup

  • MustRunAs - 사전 할당된 값을 사용하지 않는 경우 범위를 하나 이상 지정해야 합니다. 첫 번째 범위의 최솟값을 기본값으로 사용합니다. 첫 번째 범위의 첫 번째 ID에 대해 검증합니다.
  • RunAsAny - 기본값이 제공되지 않습니다. fsGroup ID를 지정할 수 있습니다.

2.1.4. 볼륨 제어

SCC의 volumes 필드를 설정하여 특정 볼륨 유형의 사용을 제어할 수 있습니다.

이 필드에 허용되는 값은 볼륨 생성 시 정의되는 볼륨 소스에 해당합니다.

새 SCC에 허용되는 볼륨의 최소 권장 집합은 configMap, downwardAPI, emptyDir, persistentVolumeClaim, secret, projected입니다.

참고

AWS의 각 Red Hat OpenShift Service 릴리스에 새로운 유형이 추가되므로 허용되는 볼륨 유형 목록은 포괄적이지 않습니다.

참고

이전 버전과의 호환성을 위해 allowHostDirVolumePlugin을 사용하면 volumes 필드의 설정을 덮어씁니다. 예를 들어, allowHostDirVolumePlugin이 false로 설정되어 있지만 volumes 필드에서 허용되는 경우 volumes에서 hostPath 값이 제거됩니다.

2.1.5. 승인 제어

SCC를 통한 허용 제어를 사용하면 사용자에게 부여된 기능을 기반으로 리소스 생성을 제어할 수 있습니다.

SCC 측면에서는 허용 컨트롤러가 컨텍스트에서 사용 가능한 사용자 정보를 검사하여 적절한 SCC 집합을 검색할 수 있음을 의미합니다. 이 경우 Pod에 운영 환경에 대한 요청을 하거나 Pod에 적용할 일련의 제약 조건을 생성할 수 있는 권한이 부여됩니다.

허용 작업에서 Pod를 승인하는 데 사용하는 SCC 집합은 사용자 ID 및 사용자가 속하는 그룹에 따라 결정됩니다. 또한 Pod에서 서비스 계정을 지정하는 경우, 허용된 SCC 집합에 서비스 계정에 액세스할 수 있는 모든 제약 조건이 포함됩니다.

허용 작업에서는 다음 방법을 사용하여 Pod에 대한 최종 보안 컨텍스트를 생성합니다.

  1. 사용 가능한 모든 SCC를 검색합니다.
  2. 요청에 지정되지 않은 보안 컨텍스트 설정에 대한 필드 값을 생성합니다.
  3. 사용 가능한 제약 조건에 대해 최종 설정을 검증합니다.

일치하는 제약 조건 집합이 있는 경우 Pod가 승인됩니다. 요청을 SCC와 일치시킬 수 없는 경우 Pod가 거부됩니다.

Pod는 SCC에 대해 모든 필드를 검증해야 합니다. 다음은 검증이 필요한 필드 중 단 2개의 예입니다.

참고

이러한 예제는 사전 할당된 값을 사용하는 전략 컨텍스트에 있습니다.

MustRunAs의 FSGroup SCC 전략

Pod에서 fsGroup ID를 정의하는 경우 해당 ID는 기본 fsGroup ID와 같아야 합니다. 그렇지 않으면 해당 SCC에서 Pod를 검증하지 않고 다음 SCC를 평가합니다.

SecurityContextConstraints.fsGroup 필드에 값 RunAsAny가 있고 Pod 사양에서 Pod.spec.securityContext.fsGroup을 생략하는 경우, 이 필드는 유효한 것으로 간주됩니다. 유효성을 확인하는 동안 다른 SCC 설정에서 다른 Pod 필드를 거부하여 Pod가 실패할 수 있습니다.

MustRunAsSupplementalGroups SCC 전략

Pod 사양에서 하나 이상의 supplementalGroups ID를 정의하는 경우, Pod의 ID는 네임스페이스의 openshift.io/sa.scc.supplemental-groups 주석에 있는 ID 중 하나와 같아야 합니다. 그렇지 않으면 해당 SCC에서 Pod를 검증하지 않고 다음 SCC를 평가합니다.

SecurityContextConstraints.supplementalGroups 필드에 값 RunAsAny가 있고 Pod 사양에서 Pod.spec.securityContext.supplementalGroups를 생략하는 경우, 이 필드는 유효한 것으로 간주됩니다. 유효성을 확인하는 동안 다른 SCC 설정에서 다른 Pod 필드를 거부하여 Pod가 실패할 수 있습니다.

2.1.6. 보안 컨텍스트 제약 조건 우선순위 지정

SCC(보안 컨텍스트 제약 조건)에는 승인 컨트롤러의 요청을 확인할 때 순서에 영향을 주는 우선순위 필드가 있습니다.

우선순위 값 0 은 가능한 가장 낮은 우선 순위입니다. nil 우선순위는 0 또는 가장 낮은 우선 순위로 간주됩니다. 우선순위가 높은 SCC는 정렬 시 세트 앞쪽으로 이동합니다.

사용 가능한 SCC 전체 세트가 결정되면 SCC가 다음과 같은 방식으로 정렬됩니다.

  1. 우선순위가 가장 높은 SCC가 먼저 정렬됩니다.
  2. 우선순위가 동일하면 SCC가 가장 제한적인 것에서 덜 제한적인 순으로 정렬됩니다.
  3. 우선순위 및 제한이 모두 같은 경우 SCC는 이름별로 정렬됩니다.

기본적으로 클러스터 관리자에게 부여되는 anyuid SCC는 SCC 집합에서 우선순위가 부여됩니다. 이를 통해 클러스터 관리자는 Pod의 SecurityContextRunAsUser 를 지정하여 모든 사용자로 Pod를 실행할 수 있습니다.

2.2. 미리 할당된 보안 컨텍스트 제약 조건 값 정보

허용 컨트롤러는 SCC(보안 컨텍스트 제약 조건)의 특정 조건을 인식하여 네임스페이스에서 미리 할당된 값을 조회하고 pod를 처리하기 전에 SCC를 채울 수 있습니다. 각 SCC 전략은 실행 중인 pod에 정의된 다양한 ID에 대한 최종 값을 만들기 위해 pod 사양 값으로 집계된 각 정책에 대해, 허용된 경우 사전 할당된 값을 사용하여 다른 전략과 독립적으로 평가됩니다.

다음 SCC를 사용하면 Pod 사양에 범위가 정의되지 않은 경우 허용 컨트롤러에서 사전 할당된 값을 찾습니다.

  1. 최소 또는 최대 집합이 없는 MustRunAsRangeRunAsUser 전략. 허용 작업에서는 범위 필드를 채우기 위해 openshift.io/sa.scc.uid-range 주석을 찾습니다.
  2. 수준이 설정되지 않은 MustRunAsSELinuxContext 전략. 허용 작업에서는 수준을 채울 openshift.io/sa.scc.mcs 주석을 찾습니다.
  3. MustRunAsFSGroup 전략. 허용 작업에서는 openshift.io/sa.scc.supplemental-group 주석을 찾습니다.
  4. MustRunAsSupplementalGroups 전략. 허용 작업에서는 openshift.io/sa.scc.supplemental-group 주석을 찾습니다.

생성 단계 중 보안 컨텍스트 공급자는 Pod에서 구체적으로 설정되지 않은 모든 매개변수 값으로 기본값을 사용합니다. 기본값은 선택한 전략에 따라 다릅니다.

  1. RunAsAnyMustRunAsNonRoot 전략에서는 기본값을 제공하지 않습니다. Pod에 그룹 ID와 같은 매개변수 값이 필요한 경우, Pod 사양에 값을 정의해야 합니다.
  2. MustRunAs (단일 값) 전략에서는 항상 사용되는 기본값을 제공합니다. 예를 들어, 그룹 ID의 경우 Pod 사양에서 고유한 ID 값을 정의하더라도 네임스페이스의 기본 매개변수 값도 Pod의 그룹에 나타납니다.
  3. MustRunAsRangeMustRunAs (범위 기반) 전략에서는 최소 범위 값을 제공합니다. 단일 값 MustRunAs 전략과 마찬가지로 네임스페이스의 기본 매개 변수 값이 실행 중인 Pod에 나타납니다. 범위 기반 전략을 여러 범위로 구성할 수 있는 경우, 처음 구성된 최소 범위 값을 제공합니다.
참고

openshift.io/sa.scc.supplemental-groups 주석이 네임스페이스에 존재하지 않는 경우, FSGroupSupplementalGroups 전략이 openshift.io/sa.scc.uid-range 주석으로 변경됩니다. 둘 다 존재하지 않으면 SCC가 생성되지 않습니다.

참고

기본적으로 주석 기반 FSGroup 전략은 주석의 최솟값에 따라 단일 범위로 자체 구성됩니다. 예를 들어, 주석이 1/3이면 FSGroup 전략은 최솟값이자 최댓값인 1로 구성됩니다. FSGroup 필드에 더 많은 그룹을 허용하려면 주석을 사용하지 않는 사용자 정의 SCC를 구성하면 됩니다.

참고

openshift.io/sa.scc.supplemental-groups 주석에는 <start>/<length 또는 <start>-<end> 형식의 쉼표로 구분된 블록 목록을 사용할 수 있습니다. openshift.io/sa.scc.uid-range 주석에는 단일 블록만 사용할 수 있습니다.

2.3. 보안 컨텍스트 제약 조건의 예

다음 예에서는 SCC(보안 컨텍스트 제약 조건)의 형식 및 주석을 보여줍니다.

주석이 달린 권한 있는 SCC

allowHostDirVolumePlugin: true
allowHostIPC: true
allowHostNetwork: true
allowHostPID: true
allowHostPorts: true
allowPrivilegedContainer: true
allowedCapabilities: 1
- '*'
apiVersion: security.openshift.io/v1
defaultAddCapabilities: [] 2
fsGroup: 3
  type: RunAsAny
groups: 4
- system:cluster-admins
- system:nodes
kind: SecurityContextConstraints
metadata:
  annotations:
    kubernetes.io/description: 'privileged allows access to all privileged and host
      features and the ability to run as any user, any group, any fsGroup, and with
      any SELinux context.  WARNING: this is the most relaxed SCC and should be used
      only for cluster administration. Grant with caution.'
  creationTimestamp: null
  name: privileged
priority: null
readOnlyRootFilesystem: false
requiredDropCapabilities: 5
- KILL
- MKNOD
- SETUID
- SETGID
runAsUser: 6
  type: RunAsAny
seLinuxContext: 7
  type: RunAsAny
seccompProfiles:
- '*'
supplementalGroups: 8
  type: RunAsAny
users: 9
- system:serviceaccount:default:registry
- system:serviceaccount:default:router
- system:serviceaccount:openshift-infra:build-controller
volumes: 10
- '*'

1
pod에서 요청할 수 있는 기능 목록입니다. 빈 목록은 기능을 요청할 수 없음을 나타내고, 특수 기호 *는 모든 기능을 요청할 수 있음을 나타냅니다.
2
임의의 pod에 추가된 추가 기능 목록입니다.
3
보안 컨텍스트에 허용되는 값을 지시하는 FSGroup 전략입니다.
4
이 SCC에 액세스할 수 있는 그룹입니다.
5
Pod에서 삭제할 기능 목록입니다. 또는 ALL 을 지정하여 모든 기능을 삭제합니다.
6
보안 컨텍스트에 허용되는 값을 지시하는 runAsUser 전략 유형입니다.
7
보안 컨텍스트에 허용되는 값을 지시하는 seLinuxContext 전략 유형입니다.
8
security 컨텍스트에 허용되는 추가 그룹을 지시하는 supplementalGroups 전략입니다.
9
이 SCC에 액세스할 수 있는 사용자입니다.
10
보안 컨텍스트에 허용되는 볼륨 유형입니다. 이 예에서 * 는 모든 볼륨 유형을 사용할 수 있습니다.

SCC의 usersgroups 필드는 SCC에 액세스할 수 있는 사용자를 제어합니다. 기본적으로 클러스터 관리자, 노드 및 빌드 컨트롤러에는 권한 있는 SCC에 대한 액세스 권한이 부여됩니다. 인증된 모든 사용자에게 restricted-v2 SCC에 대한 액세스 권한이 부여됩니다.

명시적인 runAsUser 설정이 없는 경우

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext: 1
  containers:
  - name: sec-ctx-demo
    image: gcr.io/google-samples/node-hello:1.0

1
컨테이너 또는 pod에서 실행해야 하는 사용자 ID를 요청하지 않는 경우, 유효 UID는 이 pod를 내보내는 SCC에 따라 다릅니다. restricted-v2 SCC는 기본적으로 인증된 모든 사용자에게 부여되므로 모든 사용자 및 서비스 계정에서 사용할 수 있으며 대부분의 경우 사용할 수 있습니다. restricted-v2 SCC는 securityContext.runAsUser 필드의 가능한 값을 제한하고 기본값을 설정하는 데 MustRunAsRange 전략을 사용합니다. 허용 플러그인은 이 범위를 제공하지 않으므로 현재 프로젝트에서 openshift.io/sa.scc.uid-range 주석을 찾아 범위 필드를 채웁니다. 결국 컨테이너에는 모든 프로젝트의 범위가 다르기 때문에 예측하기 어려운 범위의 첫 번째 값과 동일한 runAsUser가 있게 됩니다.

명시적인 runAsUser 설정

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000 1
  containers:
    - name: sec-ctx-demo
      image: gcr.io/google-samples/node-hello:1.0

1
특정 사용자 ID를 요청하는 컨테이너 또는 포드는 서비스 계정 또는 사용자에게 이러한 사용자 ID를 허용하는 SCC에 대한 액세스 권한이 부여된 경우에만 AWS의 Red Hat OpenShift Service에서 승인됩니다. SCC를 사용하면 임의의 ID, 특정 범위에 속하는 ID 또는 요청과 관련된 정확한 사용자 ID를 허용할 수 있습니다.

이 구성은 SELinux, fsGroup 및 추가 그룹에 유효합니다.

2.4. 보안 컨텍스트 제약 조건 생성

OpenShift CLI(oc)를 사용하여 SCC(보안 컨텍스트 제약 조건)를 생성할 수 있습니다.

중요

자체 SCC를 생성하고 수정하면 클러스터에 불안정할 수 있는 고급 작업입니다. 자체 SCC 사용에 대한 질문이 있는 경우 Red Hat 지원에 문의하십시오. Red Hat 지원 문의에 대한 자세한 내용은 지원 시작하기 를 참조하십시오.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할의 사용자로 클러스터에 로그인합니다.

절차

  1. 이름이 scc-admin.yaml 인 YAML 파일에 SCC를 정의합니다.

    kind: SecurityContextConstraints
    apiVersion: security.openshift.io/v1
    metadata:
      name: scc-admin
    allowPrivilegedContainer: true
    runAsUser:
      type: RunAsAny
    seLinuxContext:
      type: RunAsAny
    fsGroup:
      type: RunAsAny
    supplementalGroups:
      type: RunAsAny
    users:
    - my-admin-user
    groups:
    - my-admin-group

    필요한 경우 requiredDropCapabilities 필드를 원하는 값으로 설정하여 SCC에 대한 특정 기능을 삭제할 수 있습니다. 지정된 기능은 컨테이너에서 삭제됩니다. 모든 기능을 삭제하려면 ALL 을 지정합니다. 예를 들어 KILL,MKNOD, SYS_CHROOT 기능을 삭제하는 SCC를 생성하려면 SCC 오브젝트에 다음을 추가합니다.

    requiredDropCapabilities:
    - KILL
    - MKNOD
    - SYS_CHROOT
    참고

    allowedCapabilitiesrequiredDropCapabilities 에서 기능을 나열할 수 없습니다.

    CRI-O는 Docker 문서에 있는 동일한 기능 값 목록을 지원합니다.

  2. 파일에서 전달하여 SCC 생성:

    $ oc create -f scc-admin.yaml

    출력 예

    securitycontextconstraints "scc-admin" created

검증

  • SCC가 생성되었는지 확인합니다.

    $ oc get scc scc-admin

    출력 예

    NAME        PRIV      CAPS      SELINUX    RUNASUSER   FSGROUP    SUPGROUP   PRIORITY   READONLYROOTFS   VOLUMES
    scc-admin   true      []        RunAsAny   RunAsAny    RunAsAny   RunAsAny   <none>     false            [awsElasticBlockStore azureDisk azureFile cephFS cinder configMap downwardAPI emptyDir fc flexVolume flocker gcePersistentDisk gitRepo glusterfs iscsi nfs persistentVolumeClaim photonPersistentDisk quobyte rbd secret vsphere]

2.5. 보안 컨텍스트 제약 조건에 대한 역할 기반 액세스

SBA를 RBAC에서 처리하는 리소스로 지정할 수 있습니다. 그러면 SCC에 대한 액세스 권한의 범위를 특정 프로젝트 또는 전체 클러스터로 지정할 수 있습니다. SCC에 사용자, 그룹 또는 서비스 계정을 직접 할당하면 클러스터 전체 범위가 유지됩니다.

참고

기본 네임스페이스(default, kube-system, kube-public, openshift-node, openshift-infra, openshift) 중 하나에서 생성된 Pod에는 SCC를 할당할 수 없습니다. 이러한 네임스페이스는 Pod 또는 서비스를 실행하는 데 사용해서는 안 됩니다.

역할에 대한 SCC 액세스 권한을 포함하려면 역할을 생성할 때 scc 리소스를 지정하십시오.

$ oc create role <role-name> --verb=use --resource=scc --resource-name=<scc-name> -n <namespace>

그러면 다음과 같은 역할 정의가 생성됩니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
...
  name: role-name 1
  namespace: namespace 2
...
rules:
- apiGroups:
  - security.openshift.io 3
  resourceNames:
  - scc-name 4
  resources:
  - securitycontextconstraints 5
  verbs: 6
  - use
1
역할의 이름입니다.
2
정의된 역할의 네임스페이스입니다. 지정하지 않는 경우 기본값은 default입니다.
3
SecurityContextConstraints 리소스를 포함하는 API 그룹입니다. scc가 리소스로 지정되면 자동으로 정의됩니다.
4
액세스할 SCC 이름의 예입니다.
5
사용자가 resourceNames 필드에 SCC 이름을 지정할 수 있는 리소스 그룹의 이름입니다.
6
역할에 적용할 동사 목록입니다.

이러한 규칙이 있는 로컬 또는 클러스터 역할을 통해 RoleBinding 또는 ClusterRoleBinding으로 바인딩된 주체는 scc-name이라는 사용자 정의 SCC를 사용할 수 있습니다.

참고

RBAC는 에스컬레이션되지 않도록 설계되었으므로 프로젝트 관리자도 SCC에 대한 액세스 권한을 부여할 수 없습니다. restricted-v2 SCC를 포함하여 기본적으로 SCC 리소스에 동사 use 를 사용할 수 없습니다.

2.6. 보안 컨텍스트 제약 조건 명령 참조

OpenShift CLI (oc)를 사용하여 인스턴스의 SCC(보안 컨텍스트 제약 조건)를 일반 API 오브젝트로 관리할 수 있습니다.

2.6.1. 보안 컨텍스트 제약 조건 나열

현재 SCC 목록을 가져오려면 다음을 실행합니다.

$ oc get scc

출력 예

NAME                              PRIV    CAPS                   SELINUX     RUNASUSER          FSGROUP     SUPGROUP    PRIORITY     READONLYROOTFS   VOLUMES
anyuid                            false   <no value>             MustRunAs   RunAsAny           RunAsAny    RunAsAny    10           false            ["configMap","downwardAPI","emptyDir","persistentVolumeClaim","projected","secret"]
hostaccess                        false   <no value>             MustRunAs   MustRunAsRange     MustRunAs   RunAsAny    <no value>   false            ["configMap","downwardAPI","emptyDir","hostPath","persistentVolumeClaim","projected","secret"]
hostmount-anyuid                  false   <no value>             MustRunAs   RunAsAny           RunAsAny    RunAsAny    <no value>   false            ["configMap","downwardAPI","emptyDir","hostPath","nfs","persistentVolumeClaim","projected","secret"]
hostnetwork                       false   <no value>             MustRunAs   MustRunAsRange     MustRunAs   MustRunAs   <no value>   false            ["configMap","downwardAPI","emptyDir","persistentVolumeClaim","projected","secret"]
hostnetwork-v2                    false   ["NET_BIND_SERVICE"]   MustRunAs   MustRunAsRange     MustRunAs   MustRunAs   <no value>   false            ["configMap","downwardAPI","emptyDir","persistentVolumeClaim","projected","secret"]
node-exporter                     true    <no value>             RunAsAny    RunAsAny           RunAsAny    RunAsAny    <no value>   false            ["*"]
nonroot                           false   <no value>             MustRunAs   MustRunAsNonRoot   RunAsAny    RunAsAny    <no value>   false            ["configMap","downwardAPI","emptyDir","persistentVolumeClaim","projected","secret"]
nonroot-v2                        false   ["NET_BIND_SERVICE"]   MustRunAs   MustRunAsNonRoot   RunAsAny    RunAsAny    <no value>   false            ["configMap","downwardAPI","emptyDir","persistentVolumeClaim","projected","secret"]
privileged                        true    ["*"]                  RunAsAny    RunAsAny           RunAsAny    RunAsAny    <no value>   false            ["*"]
restricted                        false   <no value>             MustRunAs   MustRunAsRange     MustRunAs   RunAsAny    <no value>   false            ["configMap","downwardAPI","emptyDir","persistentVolumeClaim","projected","secret"]
restricted-v2                     false   ["NET_BIND_SERVICE"]   MustRunAs   MustRunAsRange     MustRunAs   RunAsAny    <no value>   false            ["configMap","downwardAPI","emptyDir","persistentVolumeClaim","projected","secret"]

2.6.2. 보안 컨텍스트 제약 조건 검사

SCC가 적용되는 사용자, 서비스 계정 및 그룹을 포함하여 특정 SCC에 대한 정보를 볼 수 있습니다.

예를 들어 restricted SCC를 검사하려면 다음을 실행합니다.

$ oc describe scc restricted

출력 예

Name:                                  restricted
Priority:                              <none>
Access:
  Users:                               <none> 1
  Groups:                              <none> 2
Settings:
  Allow Privileged:                    false
  Allow Privilege Escalation:          true
  Default Add Capabilities:            <none>
  Required Drop Capabilities:          KILL,MKNOD,SETUID,SETGID
  Allowed Capabilities:                <none>
  Allowed Seccomp Profiles:            <none>
  Allowed Volume Types:                configMap,downwardAPI,emptyDir,persistentVolumeClaim,projected,secret
  Allowed Flexvolumes:                 <all>
  Allowed Unsafe Sysctls:              <none>
  Forbidden Sysctls:                   <none>
  Allow Host Network:                  false
  Allow Host Ports:                    false
  Allow Host PID:                      false
  Allow Host IPC:                      false
  Read Only Root Filesystem:           false
  Run As User Strategy: MustRunAsRange
    UID:                               <none>
    UID Range Min:                     <none>
    UID Range Max:                     <none>
  SELinux Context Strategy: MustRunAs
    User:                              <none>
    Role:                              <none>
    Type:                              <none>
    Level:                             <none>
  FSGroup Strategy: MustRunAs
    Ranges:                            <none>
  Supplemental Groups Strategy: RunAsAny
    Ranges:                            <none>

1
SCC가 적용되는 사용자 및 서비스 계정을 나열합니다.
2
SCC가 적용되는 그룹을 나열합니다.

2.7. 추가 리소스

법적 공지

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.