인증 및 권한 부여
AWS 클러스터에서 Red Hat OpenShift Service 보안
초록
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 워크플로

워크플로는 다음 단계가 있습니다.
-
사용자 정의 프로젝트에서 사용자는
eks.amazonaws.com/role-arn주석을 포함하는 서비스 계정을 생성합니다. 주석은 서비스 계정에서 가정할 AWS IAM 역할의 ARN을 가리킵니다. 주석이 있는 서비스 계정을 참조하는 구성을 사용하여 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토큰파일은 볼륨에 포함되어 있습니다.
-
AWS SDK 작업을 실행하는 데 필요한 권한이 있는 IAM 역할에 대한 ARN이 포함된
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이 포함되어 있습니다.
- 프로젝트 및 서비스 계정이 가정 중인 IAM 역할에 대한 신뢰 정책 범위에 있는 경우 권한 부여가 성공합니다.
- 인증 및 권한 부여가 성공하면 세션 토큰 형식의 임시 AWS STS 인증 정보가 서비스 계정에서 사용할 수 있도록 Pod로 전달됩니다. 인증 정보를 사용하면 서비스 계정에 IAM 역할에서 활성화된 AWS 권한이 일시적으로 부여됩니다.
- 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)가 설치되어 있습니다.
절차
다음 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로 교체해야 합니다.
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출력 예:
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>입니다.서비스 계정이 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- 선택 사항: 사용자 지정 특성 또는 권한 경계를 역할에 추가합니다. 자세한 내용은 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)가 설치되어 있습니다.
절차
Red Hat OpenShift Service on AWS 클러스터에서 프로젝트를 생성합니다.
$ oc new-project <project_name> 1- 1
- &
lt;project_name>을 프로젝트 이름으로 바꿉니다. 이름은 AWS IAM 역할 구성에 지정한 프로젝트 이름과 일치해야 합니다.
참고프로젝트가 생성되면 자동으로 프로젝트로 전환됩니다.
다음 서비스 계정 구성을 사용하여
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>입니다.
프로젝트에서 서비스 계정을 생성합니다.
$ oc create -f test-service-account.yaml
출력 예:
serviceaccount/<service_account_name> created
서비스 계정의 세부 정보를 검토합니다.
$ 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 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 사용자 계정이 있습니다.
절차
Containerfile이라는 파일에 다음 구성을 추가합니다.FROM ubi9/ubi 1 RUN dnf makecache && dnf install -y python3-pip && dnf clean all && pip3 install boto3>=1.15.0 2
파일이 포함된 디렉터리에서
awsboto3sdk라는 컨테이너 이미지를 빌드합니다.$ podman build -t awsboto3sdk .
Quay.io에 로그인합니다.
$ podman login quay.io
Quay.io에 업로드할 준비를 위해 이미지에 태그를 지정합니다.
$ podman tag localhost/awsboto3sdk quay.io/<quay_username>/awsboto3sdk:latest 1- 1
- <
;quay_username>을 Quay.io 사용자 이름으로 교체합니다.
태그된 컨테이너 이미지를 Quay.io로 푸시합니다.
$ podman push quay.io/<quay_username>/awsboto3sdk:latest 1- 1
- <
;quay_username>을 Quay.io 사용자 이름으로 교체합니다.
이미지가 public으로 포함된 Quay.io 리포지토리를 만듭니다. 이렇게 하면 AWS 클러스터에 Red Hat OpenShift Service에 Pod를 배포하는 데 사용할 수 있는 이미지가 게시됩니다.
- https://quay.io/ 에서 이미지가 포함된 리포지토리의 리포지토리 설정 페이지로 이동합니다.
- 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 및 툴 참조 가이드를 참조하십시오.
절차
다음 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컨테이너 이미지의 위치를 지정합니다. <quay_username>을 Quay.io 사용자 이름으로 교체합니다.- 5
- 이 예제 Pod 구성에서는 이 줄에서 100000초 동안 Pod를 실행하여 Pod에서 직접 검증 테스트를 수행할 수 있습니다. 자세한 확인 단계는 Pod에서 가정된 IAM 역할 확인을 참조하십시오.
awsboto3sdkPod를 배포합니다.$ 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 및 툴 참조 가이드를 참조하십시오.
절차
AWS 환경 변수, 볼륨 마운트 및 OIDC 토큰 볼륨이 배포된
awsboto3sdkPod 설명에 나열되어 있는지 확인합니다.$ 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 토큰이 포함되어 있습니다.
awsboto3sdkPod에서 대화형 터미널을 시작합니다.$ oc exec -ti awsboto3sdk -- /bin/sh
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을 지정해야 합니다.
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의 전체 경로를 지정해야 합니다.
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)
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를 인증하는 데 사용됩니다.
Pod에서 AWS Boto3 SDK 작업이 성공적으로 실행되는지 확인합니다.
Pod의 대화형 터미널에서 Python 3 쉘을 시작합니다.
$ python3
Python 3 쉘에서
boto3모듈을 가져옵니다.>>> import boto3
Boto3
s3서비스 리소스를 포함하는 변수를 생성합니다.>>> s3 = boto3.resource('s3')AWS 계정에 있는 모든 S3 버킷의 이름을 출력합니다.
>>> for bucket in s3.buckets.all(): ... print(bucket.name) ...
출력 예:
<bucket_name> <bucket_name> <bucket_name> ...
서비스 계정이 AWS IAM 역할로 가정하면 출력에 AWS 계정에서 사용할 수 있는 모든 S3 버킷이 나열됩니다.
1.3. 추가 리소스
- 서비스 계정과 AWS IAM 역할을 사용하는 방법에 대한 자세한 내용은 AWS 문서의 서비스 계정 IAM 역할을 참조하십시오.
- AWS IAM 역할 위임에 대한 자세한 내용은 AWS 문서의 AWS 서비스에 권한을 위임하는 역할 생성을 참조하십시오.
- AWS SDK에 대한 자세한 내용은 AWS 문서의 AWS SDK 및 툴 참조 가이드를 참조하십시오.
- AWS Boto3 SDK for Python 설치 및 사용에 대한 자세한 내용은 AWS Boto3 문서를 참조하십시오.
- OpenShift의 웹 후크 승인 플러그인에 대한 일반적인 내용은 OpenShift Container Platform 설명서의 Webhook 승인 플러그인 을 참조하십시오.
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. 기본 보안 컨텍스트 제약 조건
| 보안 컨텍스트 제약 조건 | 설명 |
|---|---|
|
|
|
|
| 모든 호스트 네임스페이스에 액세스할 수 있지만 네임스페이스에 할당된 UID 및 SELinux 컨텍스트를 사용하여 pod를 실행해야 합니다. 주의 이 SCC를 사용하면 네임스페이스, 파일 시스템 및 PID에 대한 호스트 액세스를 허용합니다. 신뢰할 수 있는 pod에서만 사용해야 합니다. 주의해서 실행합니다. |
|
|
주의 이 SCC를 사용하면 UID 0을 포함하여 모든 UID로 호스트 파일 시스템에 액세스할 수 있습니다. 주의해서 실행합니다. |
|
| 호스트 네트워킹 및 호스트 포트를 사용할 수 있지만 네임스페이스에 할당된 UID 및 SELinux 컨텍스트로 pod를 실행해야 합니다. 주의
컨트롤 플레인 호스트에서 추가 워크로드가 실행되는 경우 |
|
|
|
|
| Prometheus 노드 내보내기에 사용됩니다. 주의 이 SCC를 사용하면 UID 0을 포함하여 모든 UID로 호스트 파일 시스템에 액세스할 수 있습니다. 주의해서 실행합니다. |
|
|
|
|
|
|
|
| 모든 권한 및 호스트 기능에 대한 액세스를 허용하고 모든 사용자, 그룹, FSGroup 및 모든 SELinux 컨텍스트로 실행할 수 있습니다. 주의 이는 가장 완화된 SCC이며 클러스터 관리에만 사용해야 합니다. 주의해서 실행합니다.
참고
Pod 사양에서 |
|
| 모든 호스트 기능에 대한 액세스를 거부하고 네임스페이스에 할당된 UID 및 SELinux 컨텍스트로 Pod를 실행해야 합니다.
AWS 4.10 또는 이전 버전에서 Red Hat OpenShift Service에서 업그레이드된 클러스터에서는 인증된 사용자가 이 SCC를 사용할 수 있습니다. 액세스 권한이 명시적으로 부여되지 않는 한 |
|
|
이는 새 설치에서 제공하는 가장 제한적인 SCC이며 인증된 사용자에게 기본적으로 사용됩니다. 참고
|
2.1.2. 보안 컨텍스트 제약 조건 설정
SCC(보안 컨텍스트 제약 조건)는 pod에서 액세스할 수 있는 보안 기능을 제어하는 설정 및 전략으로 구성됩니다. 이 설정은 세 가지 범주로 분류됩니다.
| 카테고리 | 설명 |
|---|---|
| 부울로 제어 |
이 유형의 필드는 기본적으로 가장 제한적인 값으로 설정됩니다. 예를 들어, |
| 허용 가능한 설정으로 제어 | 이 유형의 필드는 해당 값이 허용되는지 확인하기 위해 설정과 대조됩니다. |
| 전략으로 제어 | 가치를 생성하는 전략이 있는 항목에서는 다음을 제공합니다.
|
CRI-O에는 Pod의 각 컨테이너에 허용되는 다음 기본 기능 목록이 있습니다.
-
CHOWN -
DAC_OVERRIDE -
FSETID -
FOWNER -
SETGID -
SETUID -
SETPCAP -
NET_BIND_SERVICE -
KILL
컨테이너에서는 이 기본 목록의 기능을 사용하지만 Pod 매니페스트 작성자는 추가 기능을 요청하거나 일부 기본 동작을 제거하여 목록을 변경할 수 있습니다. allowedCapabilities,defaultAddCapabilities 및 requiredDropCapabilities 매개변수를 사용하여 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- 기본값이 제공되지 않습니다.fsGroupID를 지정할 수 있습니다.
2.1.4. 볼륨 제어
SCC의 volumes 필드를 설정하여 특정 볼륨 유형의 사용을 제어할 수 있습니다.
이 필드에 허용되는 값은 볼륨 생성 시 정의되는 볼륨 소스에 해당합니다.
-
awsElasticBlockStore -
azureDisk -
azureFile -
cephFS -
cinder -
configMap -
csi -
downwardAPI -
emptyDir -
fc -
flexVolume -
flocker -
gcePersistentDisk -
gitRepo -
glusterfs -
hostPath -
iscsi -
nfs -
persistentVolumeClaim -
photonPersistentDisk -
portworxVolume -
projected -
quobyte -
rbd -
scaleIO -
secret -
storageos -
vsphereVolume - * (모든 볼륨 유형의 사용을 허용하는 특수 값)
-
none(모든 볼륨 유형의 사용을 허용하지 않는 특수 값입니다. 이전 버전과의 호환성을 위해서만 존재합니다.)
새 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에 대한 최종 보안 컨텍스트를 생성합니다.
- 사용 가능한 모든 SCC를 검색합니다.
- 요청에 지정되지 않은 보안 컨텍스트 설정에 대한 필드 값을 생성합니다.
- 사용 가능한 제약 조건에 대해 최종 설정을 검증합니다.
일치하는 제약 조건 집합이 있는 경우 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가 실패할 수 있습니다.
MustRunAs의 SupplementalGroups 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가 다음과 같은 방식으로 정렬됩니다.
- 우선순위가 가장 높은 SCC가 먼저 정렬됩니다.
- 우선순위가 동일하면 SCC가 가장 제한적인 것에서 덜 제한적인 순으로 정렬됩니다.
- 우선순위 및 제한이 모두 같은 경우 SCC는 이름별로 정렬됩니다.
기본적으로 클러스터 관리자에게 부여되는 anyuid SCC는 SCC 집합에서 우선순위가 부여됩니다. 이를 통해 클러스터 관리자는 Pod의 SecurityContext 에 RunAsUser 를 지정하여 모든 사용자로 Pod를 실행할 수 있습니다.
2.2. 미리 할당된 보안 컨텍스트 제약 조건 값 정보
허용 컨트롤러는 SCC(보안 컨텍스트 제약 조건)의 특정 조건을 인식하여 네임스페이스에서 미리 할당된 값을 조회하고 pod를 처리하기 전에 SCC를 채울 수 있습니다. 각 SCC 전략은 실행 중인 pod에 정의된 다양한 ID에 대한 최종 값을 만들기 위해 pod 사양 값으로 집계된 각 정책에 대해, 허용된 경우 사전 할당된 값을 사용하여 다른 전략과 독립적으로 평가됩니다.
다음 SCC를 사용하면 Pod 사양에 범위가 정의되지 않은 경우 허용 컨트롤러에서 사전 할당된 값을 찾습니다.
-
최소 또는 최대 집합이 없는
MustRunAsRange의RunAsUser전략. 허용 작업에서는 범위 필드를 채우기 위해openshift.io/sa.scc.uid-range주석을 찾습니다. -
수준이 설정되지 않은
MustRunAs의SELinuxContext전략. 허용 작업에서는 수준을 채울openshift.io/sa.scc.mcs주석을 찾습니다. -
MustRunAs의FSGroup전략. 허용 작업에서는openshift.io/sa.scc.supplemental-group주석을 찾습니다. -
MustRunAs의SupplementalGroups전략. 허용 작업에서는openshift.io/sa.scc.supplemental-group주석을 찾습니다.
생성 단계 중 보안 컨텍스트 공급자는 Pod에서 구체적으로 설정되지 않은 모든 매개변수 값으로 기본값을 사용합니다. 기본값은 선택한 전략에 따라 다릅니다.
-
RunAsAny및MustRunAsNonRoot전략에서는 기본값을 제공하지 않습니다. Pod에 그룹 ID와 같은 매개변수 값이 필요한 경우, Pod 사양에 값을 정의해야 합니다. -
MustRunAs(단일 값) 전략에서는 항상 사용되는 기본값을 제공합니다. 예를 들어, 그룹 ID의 경우 Pod 사양에서 고유한 ID 값을 정의하더라도 네임스페이스의 기본 매개변수 값도 Pod의 그룹에 나타납니다. -
MustRunAsRange및MustRunAs(범위 기반) 전략에서는 최소 범위 값을 제공합니다. 단일 값MustRunAs전략과 마찬가지로 네임스페이스의 기본 매개 변수 값이 실행 중인 Pod에 나타납니다. 범위 기반 전략을 여러 범위로 구성할 수 있는 경우, 처음 구성된 최소 범위 값을 제공합니다.
openshift.io/sa.scc.supplemental-groups 주석이 네임스페이스에 존재하지 않는 경우, FSGroup 및 SupplementalGroups 전략이 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의 users 및 groups 필드는 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-v2SCC는 기본적으로 인증된 모든 사용자에게 부여되므로 모든 사용자 및 서비스 계정에서 사용할 수 있으며 대부분의 경우 사용할 수 있습니다.restricted-v2SCC는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역할의 사용자로 클러스터에 로그인합니다.
절차
이름이
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
참고allowedCapabilities및requiredDropCapabilities에서 기능을 나열할 수 없습니다.CRI-O는 Docker 문서에 있는 동일한 기능 값 목록을 지원합니다.
파일에서 전달하여 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
이러한 규칙이 있는 로컬 또는 클러스터 역할을 통해 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>