Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

10장. 클라우드 공급자 인증 정보 구성 변경

지원되는 구성의 경우 OpenShift Container Platform이 클라우드 공급자로 인증하는 방법을 변경할 수 있습니다.

클러스터에서 사용하는 클라우드 인증 정보 전략을 확인하려면 Cloud Credential Operator 모드 결정을 참조하십시오.

일부 조직에서는 클러스터를 인증하는 서비스 키를 순환해야 합니다. CCO(Cloud Credential Operator) 유틸리티(ccoctl)를 사용하여 다음 클라우드 공급자에 설치된 클러스터의 키를 업데이트할 수 있습니다.

10.1.1. AWS OIDC 바인딩 서비스 계정 서명자 키 교체
링크 복사

STS를 사용하여 AWS(Amazon Web Services)의 OpenShift Container Platform 클러스터의 CCO(Cloud Credential Operator)가 수동 모드에서 작동하도록 구성된 경우 바인딩된 서비스 계정 서명자 키를 회전할 수 있습니다.

키를 교체하려면 클러스터에서 기존 키를 삭제하여 Kubernetes API 서버가 새 키를 생성합니다. 이 프로세스 중에 인증 실패를 줄이려면 기존 발행자 파일에 새 공개 키를 즉시 추가해야 합니다. 클러스터에서 인증에 새 키를 사용한 후 나머지 키를 제거할 수 있습니다.

중요

OIDC 바인딩 서비스 계정 서명자 키를 교체하는 프로세스는 중단되며 상당한 시간이 걸립니다. 일부 단계는 시간에 민감합니다. 진행하기 전에 다음 고려 사항을 고려하십시오.

  • 다음 단계를 읽고 시간 요구 사항을 이해하고 수락하는지 확인하십시오. 정확한 시간 요구 사항은 개별 클러스터에 따라 다르지만 최소 1시간이 걸릴 수 있습니다.
  • 인증 실패 위험을 줄이려면 시간에 민감한 단계를 이해하고 준비해야 합니다.
  • 이 프로세스 중에 모든 서비스 계정을 새로 고치고 클러스터의 모든 Pod를 다시 시작해야 합니다. 이러한 작업은 워크로드에 영향을 미칩니다. 이 영향을 완화하기 위해 이러한 서비스를 일시적으로 중단한 다음 클러스터가 준비되면 다시 배포할 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 OpenShift CLI(oc)에 액세스할 수 있습니다.

  • ccoctl 유틸리티에서 다음 권한과 함께 사용할 AWS 계정을 생성했습니다.

    • s3:GetObject
    • s3:PutObject
    • s3:PutObjectTagging
    • 공용 CloudFront 배포 URL을 통해 IAM ID 공급자가 액세스하는 프라이빗 S3 버킷에 OIDC 구성을 저장하는 클러스터의 경우 ccoctl 유틸리티를 실행하는 AWS 계정에 cloudfront:ListDistributions 권한이 필요합니다.
  • ccoctl 유틸리티를 구성했습니다.

  • 클러스터가 안정적인 상태에 있습니다. 다음 명령을 실행하여 클러스터가 안정적인지 확인할 수 있습니다. 

    $ oc adm wait-for-stable-cluster --minimum-stable-period=5s

프로세스

  1. 다음 환경 변수를 구성합니다. 

    INFRA_ID=$(oc get infrastructures cluster -o jsonpath='{.status.infrastructureName}')
CLUSTER_NAME=${INFRA_ID%-*}
    1
    1 1
    이 값은 설치 중에 install-config.yaml 파일의 metadata.name 필드에 지정된 클러스터의 이름과 일치해야 합니다.
    참고

    클러스터는 이 예제와 다를 수 있으며 리소스 이름은 클러스터 이름과 동일하게 파생되지 않을 수 있습니다. 클러스터의 올바른 리소스 이름을 지정해야 합니다.

    • OIDC 구성을 공용 S3 버킷에 저장하는 AWS 클러스터의 경우 다음 환경 변수를 구성합니다. 

      AWS_BUCKET=$(oc get authentication cluster -o jsonpath={'.spec.serviceAccountIssuer'} | awk -F'://' '{print$2}' |awk -F'.' '{print$1}')

    • 공개 CloudFront 배포 URL을 통해 IAM ID 공급자가 액세스하는 프라이빗 S3 버킷에 OIDC 구성을 저장하는 AWS 클러스터의 경우 다음 단계를 완료합니다.

      1. 다음 명령을 실행하여 공용 CloudFront 배포 URL을 추출합니다. 

        $ basename $(oc get authentication cluster -o jsonpath={'.spec.serviceAccountIssuer'} )

        출력 예

        <subdomain>.cloudfront.net

        여기서 <subdomain >은 영숫자 문자열입니다.

      2. 다음 명령을 실행하여 개인 S3 버킷 이름을 확인합니다. 

        $ aws cloudfront list-distributions --query "DistributionList.Items[].{DomainName: DomainName, OriginDomainName: Origins.Items[0].DomainName}[?contains(DomainName, '<subdomain>.cloudfront.net')]"

        출력 예

        [
    {
        "DomainName": "<subdomain>.cloudfront.net",
        "OriginDomainName": "<s3_bucket>.s3.us-east-2.amazonaws.com"
    }
]

        여기서 <s3_bucket >은 클러스터의 프라이빗 S3 버킷 이름입니다.

      3. 다음 환경 변수를 구성합니다. 

        AWS_BUCKET=$<s3_bucket>

        여기서 <s3_bucket >은 클러스터의 프라이빗 S3 버킷 이름입니다.

  2. 다음 명령을 실행하여 사용할 임시 디렉터리를 생성하고 환경 변수를 할당합니다. 

    $ TEMPDIR=$(mktemp -d)

  3. Kubernetes API 서버가 새 바인딩된 서비스 계정 서명 키를 생성하도록 다음 바인딩된 서비스 계정 서명 키를 삭제합니다.

    중요

    이 단계를 완료하면 Kubernetes API 서버가 새 키를 롤아웃하기 시작합니다. 인증 실패 위험을 줄이려면 나머지 단계를 최대한 빨리 완료하십시오. 나머지 단계는 워크로드에 방해가 될 수 있습니다.

    준비가 되면 다음 명령을 실행하여 다음 바인딩된 서비스 계정 서명 키를 삭제합니다. 

    $ oc delete secrets/next-bound-service-account-signing-key \
  -n openshift-kube-apiserver-operator

  4. 다음 명령을 실행하여 Kubernetes API 서버가 생성한 서비스 계정 서명 키 시크릿에서 공개 키를 다운로드합니다. 

    $ oc get secret/next-bound-service-account-signing-key \
  -n openshift-kube-apiserver-operator \
  -ojsonpath='{ .data.service-account\.pub }' | base64 \
  -d > ${TEMPDIR}/serviceaccount-signer.public

  5. 다음 명령을 실행하여 공개 키를 사용하여 keys.json 파일을 생성합니다. 

    $ ccoctl aws create-identity-provider \
  --dry-run \
    1 
    
  --output-dir ${TEMPDIR} \
  --public-key-file=${TEMPDIR}/serviceaccount-signer.public \
    2 
    
  --name fake \
    3 
    
  --region us-east-1
    4
    1
    --dry-run 옵션은 API를 호출하지 않고 새 keys.json 파일을 디스크에 포함하여 파일을 출력합니다.
    2
    이전 단계에서 다운로드한 공개 키의 경로를 지정합니다.
    3
    --dry-run 옵션은 API 호출을 수행하지 않으므로 일부 매개변수에는 실제 값이 필요하지 않습니다.
    4
    유효한 AWS 리전(예: us-east-1) 을 지정합니다. 이 값은 클러스터가 있는 리전과 일치하지 않아도 됩니다.

  6. 다음 명령을 실행하여 keys.json 파일의 이름을 변경합니다. 

    $ cp ${TEMPDIR}/<number>-keys.json ${TEMPDIR}/jwks.new.json

    여기서 <number >는 환경에 따라 달라지는 두 자리 숫자 값입니다.

  7. 다음 명령을 실행하여 클라우드 공급자에서 기존 keys.json 파일을 다운로드합니다. 

    $ aws s3api get-object \
  --bucket ${AWS_BUCKET} \
  --key keys.json ${TEMPDIR}/jwks.current.json

  8. 다음 명령을 실행하여 두 개의 keys.json 파일을 결합합니다. 

    $ jq -s '{ keys: map(.keys[])}' ${TEMPDIR}/jwks.current.json ${TEMPDIR}/jwks.new.json > ${TEMPDIR}/jwks.combined.json

  9. 교체 중에 이전 키와 새 키에 대한 인증을 활성화하려면 다음 명령을 실행하여 결합된 keys.json 파일을 클라우드 공급자에 업로드합니다. 

    $ aws s3api put-object \
  --bucket ${AWS_BUCKET} \
  --tagging "openshift.io/cloud-credential-operator/${CLUSTER_NAME}=owned" \
  --key keys.json \
  --body ${TEMPDIR}/jwks.combined.json

  10. Kubernetes API 서버가 업데이트되고 새 키를 사용할 때까지 기다립니다. 다음 명령을 실행하여 업데이트 진행 상황을 모니터링할 수 있습니다. 

    $ oc adm wait-for-stable-cluster

    이 프로세스에는 15분 이상 걸릴 수 있습니다. 다음 출력은 프로세스가 완료되었음을 나타냅니다. 

    All clusteroperators are stable

  11. 클러스터의 모든 Pod가 새 키를 사용하도록 하려면 다시 시작해야 합니다.

    중요

    이 단계에서는 여러 노드에서 고가용성을 위해 구성된 서비스의 가동 시간을 유지하지만 그렇지 않은 모든 서비스에 대해서는 다운타임이 발생할 수 있습니다.

    다음 명령을 실행하여 클러스터의 모든 Pod를 다시 시작합니다. 

    $ oc adm reboot-machine-config-pool mcp/worker mcp/master

  12. 다음 명령을 실행하여 재시작 및 업데이트 프로세스를 모니터링합니다. 

    $ oc adm wait-for-node-reboot nodes --all

    이 프로세스에는 15분 이상 걸릴 수 있습니다. 다음 출력은 프로세스가 완료되었음을 나타냅니다. 

    All nodes rebooted

  13. 다음 명령을 실행하여 업데이트 진행 상황을 모니터링합니다. 

    $ oc adm wait-for-stable-cluster

    이 프로세스에는 15분 이상 걸릴 수 있습니다. 다음 출력은 프로세스가 완료되었음을 나타냅니다. 

    All clusteroperators are stable

  14. 다음 명령을 실행하여 결합된 keys.json 파일을 클라우드 공급자에서 업데이트된 keys.json 파일로 교체합니다. 

    $ aws s3api put-object \
  --bucket ${AWS_BUCKET} \
  --tagging "openshift.io/cloud-credential-operator/${CLUSTER_NAME}=owned" \
  --key keys.json \
  --body ${TEMPDIR}/jwks.new.json

10.1.2. Google Cloud OIDC 바인딩 서비스 계정 서명자 키 교체
링크 복사

Google Cloud의 OpenShift Container Platform 클러스터의 CCO(Cloud Credential Operator)가 GCP Workload Identity를 사용하여 수동 모드에서 작동하도록 구성된 경우 바인딩된 서비스 계정 서명자 키를 회전할 수 있습니다.

키를 교체하려면 클러스터에서 기존 키를 삭제하여 Kubernetes API 서버가 새 키를 생성합니다. 이 프로세스 중에 인증 실패를 줄이려면 기존 발행자 파일에 새 공개 키를 즉시 추가해야 합니다. 클러스터에서 인증에 새 키를 사용한 후 나머지 키를 제거할 수 있습니다.

중요

OIDC 바인딩 서비스 계정 서명자 키를 교체하는 프로세스는 중단되며 상당한 시간이 걸립니다. 일부 단계는 시간에 민감합니다. 진행하기 전에 다음 고려 사항을 고려하십시오.

  • 다음 단계를 읽고 시간 요구 사항을 이해하고 수락하는지 확인하십시오. 정확한 시간 요구 사항은 개별 클러스터에 따라 다르지만 최소 1시간이 걸릴 수 있습니다.
  • 인증 실패 위험을 줄이려면 시간에 민감한 단계를 이해하고 준비해야 합니다.
  • 이 프로세스 중에 모든 서비스 계정을 새로 고치고 클러스터의 모든 Pod를 다시 시작해야 합니다. 이러한 작업은 워크로드에 영향을 미칩니다. 이 영향을 완화하기 위해 이러한 서비스를 일시적으로 중단한 다음 클러스터가 준비되면 다시 배포할 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 OpenShift CLI(oc)에 액세스할 수 있습니다.

  • ccoctl 유틸리티에서 사용하는 Google Cloud 계정에 다음 인증 옵션 중 하나를 추가했습니다.

    • IAM 워크로드 ID 풀 관리자 역할

    • 다음과 같은 세분화된 권한:

      • storage.objects.create
      • storage.objects.delete
  • ccoctl 유틸리티를 구성했습니다.

  • 클러스터가 안정적인 상태에 있습니다. 다음 명령을 실행하여 클러스터가 안정적인지 확인할 수 있습니다. 

    $ oc adm wait-for-stable-cluster --minimum-stable-period=5s

프로세스

  1. 다음 환경 변수를 구성합니다. 

    CURRENT_ISSUER=$(oc get authentication cluster -o jsonpath='{.spec.serviceAccountIssuer}')
GCP_BUCKET=$(echo ${CURRENT_ISSUER} | cut -d "/" -f4)
    참고

    클러스터는 이 예제와 다를 수 있으며 리소스 이름은 클러스터 이름과 동일하게 파생되지 않을 수 있습니다. 클러스터의 올바른 리소스 이름을 지정해야 합니다.

  2. 다음 명령을 실행하여 사용할 임시 디렉터리를 생성하고 환경 변수를 할당합니다. 

    $ TEMPDIR=$(mktemp -d)

  3. Kubernetes API 서버가 새 바인딩된 서비스 계정 서명 키를 생성하도록 다음 바인딩된 서비스 계정 서명 키를 삭제합니다.

    중요

    이 단계를 완료하면 Kubernetes API 서버가 새 키를 롤아웃하기 시작합니다. 인증 실패 위험을 줄이려면 나머지 단계를 최대한 빨리 완료하십시오. 나머지 단계는 워크로드에 방해가 될 수 있습니다.

    준비가 되면 다음 명령을 실행하여 다음 바인딩된 서비스 계정 서명 키를 삭제합니다. 

    $ oc delete secrets/next-bound-service-account-signing-key \
  -n openshift-kube-apiserver-operator

  4. 다음 명령을 실행하여 Kubernetes API 서버가 생성한 서비스 계정 서명 키 시크릿에서 공개 키를 다운로드합니다. 

    $ oc get secret/next-bound-service-account-signing-key \
  -n openshift-kube-apiserver-operator \
  -ojsonpath='{ .data.service-account\.pub }' | base64 \
  -d > ${TEMPDIR}/serviceaccount-signer.public

  5. 다음 명령을 실행하여 공개 키를 사용하여 keys.json 파일을 생성합니다. 

    $ ccoctl gcp create-workload-identity-provider \
  --dry-run \
    1 
    
  --output-dir=${TEMPDIR} \
  --public-key-file=${TEMPDIR}/serviceaccount-signer.public \
    2 
    
  --name fake \
    3 
    
  --project fake \
  --workload-identity-pool fake
    1
    --dry-run 옵션은 API를 호출하지 않고 새 keys.json 파일을 디스크에 포함하여 파일을 출력합니다.
    2
    이전 단계에서 다운로드한 공개 키의 경로를 지정합니다.
    3
    --dry-run 옵션은 API 호출을 수행하지 않으므로 일부 매개변수에는 실제 값이 필요하지 않습니다.

  6. 다음 명령을 실행하여 keys.json 파일의 이름을 변경합니다. 

    $ cp ${TEMPDIR}/<number>-keys.json ${TEMPDIR}/jwks.new.json

    여기서 <number >는 환경에 따라 달라지는 두 자리 숫자 값입니다.

  7. 다음 명령을 실행하여 클라우드 공급자에서 기존 keys.json 파일을 다운로드합니다. 

    $ gcloud storage cp gs://${GCP_BUCKET}/keys.json ${TEMPDIR}/jwks.current.json

  8. 다음 명령을 실행하여 두 개의 keys.json 파일을 결합합니다. 

    $ jq -s '{ keys: map(.keys[])}' ${TEMPDIR}/jwks.current.json ${TEMPDIR}/jwks.new.json > ${TEMPDIR}/jwks.combined.json

  9. 교체 중에 이전 키와 새 키에 대한 인증을 활성화하려면 다음 명령을 실행하여 결합된 keys.json 파일을 클라우드 공급자에 업로드합니다. 

    $ gcloud storage cp ${TEMPDIR}/jwks.combined.json gs://${GCP_BUCKET}/keys.json

  10. Kubernetes API 서버가 업데이트되고 새 키를 사용할 때까지 기다립니다. 다음 명령을 실행하여 업데이트 진행 상황을 모니터링할 수 있습니다. 

    $ oc adm wait-for-stable-cluster

    이 프로세스에는 15분 이상 걸릴 수 있습니다. 다음 출력은 프로세스가 완료되었음을 나타냅니다. 

    All clusteroperators are stable

  11. 클러스터의 모든 Pod가 새 키를 사용하도록 하려면 다시 시작해야 합니다.

    중요

    이 단계에서는 여러 노드에서 고가용성을 위해 구성된 서비스의 가동 시간을 유지하지만 그렇지 않은 모든 서비스에 대해서는 다운타임이 발생할 수 있습니다.

    다음 명령을 실행하여 클러스터의 모든 Pod를 다시 시작합니다. 

    $ oc adm reboot-machine-config-pool mcp/worker mcp/master

  12. 다음 명령을 실행하여 재시작 및 업데이트 프로세스를 모니터링합니다. 

    $ oc adm wait-for-node-reboot nodes --all

    이 프로세스에는 15분 이상 걸릴 수 있습니다. 다음 출력은 프로세스가 완료되었음을 나타냅니다. 

    All nodes rebooted

  13. 다음 명령을 실행하여 업데이트 진행 상황을 모니터링합니다. 

    $ oc adm wait-for-stable-cluster

    이 프로세스에는 15분 이상 걸릴 수 있습니다. 다음 출력은 프로세스가 완료되었음을 나타냅니다. 

    All clusteroperators are stable

  14. 다음 명령을 실행하여 결합된 keys.json 파일을 클라우드 공급자에서 업데이트된 keys.json 파일로 교체합니다. 

    $ gcloud storage cp ${TEMPDIR}/jwks.new.json gs://${GCP_BUCKET}/keys.json

10.1.3. Azure OIDC 바인딩된 서비스 계정 서명자 키 교체
링크 복사

Microsoft Azure의 OpenShift Container Platform 클러스터에 대한 CCO(Cloud Credential Operator)가 Microsoft Entra Workload ID를 사용하여 수동 모드에서 작동하도록 구성된 경우 바인딩된 서비스 계정 서명자 키를 회전할 수 있습니다.

키를 교체하려면 클러스터에서 기존 키를 삭제하여 Kubernetes API 서버가 새 키를 생성합니다. 이 프로세스 중에 인증 실패를 줄이려면 기존 발행자 파일에 새 공개 키를 즉시 추가해야 합니다. 클러스터에서 인증에 새 키를 사용한 후 나머지 키를 제거할 수 있습니다.

중요

OIDC 바인딩 서비스 계정 서명자 키를 교체하는 프로세스는 중단되며 상당한 시간이 걸립니다. 일부 단계는 시간에 민감합니다. 진행하기 전에 다음 고려 사항을 고려하십시오.

  • 다음 단계를 읽고 시간 요구 사항을 이해하고 수락하는지 확인하십시오. 정확한 시간 요구 사항은 개별 클러스터에 따라 다르지만 최소 1시간이 걸릴 수 있습니다.
  • 인증 실패 위험을 줄이려면 시간에 민감한 단계를 이해하고 준비해야 합니다.
  • 이 프로세스 중에 모든 서비스 계정을 새로 고치고 클러스터의 모든 Pod를 다시 시작해야 합니다. 이러한 작업은 워크로드에 영향을 미칩니다. 이 영향을 완화하기 위해 이러한 서비스를 일시적으로 중단한 다음 클러스터가 준비되면 다시 배포할 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 OpenShift CLI(oc)에 액세스할 수 있습니다.

  • ccoctl 유틸리티에서 다음 권한과 함께 사용할 글로벌 Azure 계정을 생성했습니다.

    • Microsoft.Storage/storageAccounts/listkeys/action
    • Microsoft.Storage/storageAccounts/read
    • Microsoft.Storage/storageAccounts/write
    • Microsoft.Storage/storageAccounts/blobServices/containers/read
    • Microsoft.Storage/storageAccounts/blobServices/containers/write
  • ccoctl 유틸리티를 구성했습니다.

  • 클러스터가 안정적인 상태에 있습니다. 다음 명령을 실행하여 클러스터가 안정적인지 확인할 수 있습니다. 

    $ oc adm wait-for-stable-cluster --minimum-stable-period=5s

프로세스

  1. 다음 환경 변수를 구성합니다. 

    CURRENT_ISSUER=$(oc get authentication cluster -o jsonpath='{.spec.serviceAccountIssuer}')
AZURE_STORAGE_ACCOUNT=$(echo ${CURRENT_ISSUER} | cut -d "/" -f3 | cut -d "." -f1)
AZURE_STORAGE_CONTAINER=$(echo ${CURRENT_ISSUER} | cut -d "/" -f4)
    참고

    클러스터는 이 예제와 다를 수 있으며 리소스 이름은 클러스터 이름과 동일하게 파생되지 않을 수 있습니다. 클러스터의 올바른 리소스 이름을 지정해야 합니다.

  2. 다음 명령을 실행하여 사용할 임시 디렉터리를 생성하고 환경 변수를 할당합니다. 

    $ TEMPDIR=$(mktemp -d)

  3. Kubernetes API 서버가 새 바인딩된 서비스 계정 서명 키를 생성하도록 다음 바인딩된 서비스 계정 서명 키를 삭제합니다.

    중요

    이 단계를 완료하면 Kubernetes API 서버가 새 키를 롤아웃하기 시작합니다. 인증 실패 위험을 줄이려면 나머지 단계를 최대한 빨리 완료하십시오. 나머지 단계는 워크로드에 방해가 될 수 있습니다.

    준비가 되면 다음 명령을 실행하여 다음 바인딩된 서비스 계정 서명 키를 삭제합니다. 

    $ oc delete secrets/next-bound-service-account-signing-key \
  -n openshift-kube-apiserver-operator

  4. 다음 명령을 실행하여 Kubernetes API 서버가 생성한 서비스 계정 서명 키 시크릿에서 공개 키를 다운로드합니다. 

    $ oc get secret/next-bound-service-account-signing-key \
  -n openshift-kube-apiserver-operator \
  -ojsonpath='{ .data.service-account\.pub }' | base64 \
  -d > ${TEMPDIR}/serviceaccount-signer.public

  5. 다음 명령을 실행하여 공개 키를 사용하여 keys.json 파일을 생성합니다. 

    $ ccoctl aws create-identity-provider \
    1 
    
  --dry-run \
    2 
    
  --output-dir ${TEMPDIR} \
  --public-key-file=${TEMPDIR}/serviceaccount-signer.public \
    3 
    
  --name fake \
    4 
    
  --region us-east-1
    5
    1
    ccoctl azure 명령에는 --dry-run 옵션이 포함되어 있지 않습니다. --dry-run 옵션을 사용하려면 Azure 클러스터에 aws 를 지정해야 합니다.
    2
    --dry-run 옵션은 API를 호출하지 않고 새 keys.json 파일을 디스크에 포함하여 파일을 출력합니다.
    3
    이전 단계에서 다운로드한 공개 키의 경로를 지정합니다.
    4
    --dry-run 옵션은 API 호출을 수행하지 않으므로 일부 매개변수에는 실제 값이 필요하지 않습니다.
    5
    유효한 AWS 리전(예: us-east-1) 을 지정합니다. 이 값은 클러스터가 있는 리전과 일치하지 않아도 됩니다.

  6. 다음 명령을 실행하여 keys.json 파일의 이름을 변경합니다. 

    $ cp ${TEMPDIR}/<number>-keys.json ${TEMPDIR}/jwks.new.json

    여기서 <number >는 환경에 따라 달라지는 두 자리 숫자 값입니다.

  7. 다음 명령을 실행하여 클라우드 공급자에서 기존 keys.json 파일을 다운로드합니다. 

    $ az storage blob download \
  --container-name ${AZURE_STORAGE_CONTAINER} \
  --account-name ${AZURE_STORAGE_ACCOUNT} \
  --name 'openid/v1/jwks' \
  -f ${TEMPDIR}/jwks.current.json

  8. 다음 명령을 실행하여 두 개의 keys.json 파일을 결합합니다. 

    $ jq -s '{ keys: map(.keys[])}' ${TEMPDIR}/jwks.current.json ${TEMPDIR}/jwks.new.json > ${TEMPDIR}/jwks.combined.json

  9. 교체 중에 이전 키와 새 키에 대한 인증을 활성화하려면 다음 명령을 실행하여 결합된 keys.json 파일을 클라우드 공급자에 업로드합니다. 

    $ az storage blob upload \
  --overwrite \
  --account-name ${AZURE_STORAGE_ACCOUNT} \
  --container-name ${AZURE_STORAGE_CONTAINER} \
  --name 'openid/v1/jwks' \
  -f ${TEMPDIR}/jwks.combined.json

  10. Kubernetes API 서버가 업데이트되고 새 키를 사용할 때까지 기다립니다. 다음 명령을 실행하여 업데이트 진행 상황을 모니터링할 수 있습니다. 

    $ oc adm wait-for-stable-cluster

    이 프로세스에는 15분 이상 걸릴 수 있습니다. 다음 출력은 프로세스가 완료되었음을 나타냅니다. 

    All clusteroperators are stable

  11. 클러스터의 모든 Pod가 새 키를 사용하도록 하려면 다시 시작해야 합니다.

    중요

    이 단계에서는 여러 노드에서 고가용성을 위해 구성된 서비스의 가동 시간을 유지하지만 그렇지 않은 모든 서비스에 대해서는 다운타임이 발생할 수 있습니다.

    다음 명령을 실행하여 클러스터의 모든 Pod를 다시 시작합니다. 

    $ oc adm reboot-machine-config-pool mcp/worker mcp/master

  12. 다음 명령을 실행하여 재시작 및 업데이트 프로세스를 모니터링합니다. 

    $ oc adm wait-for-node-reboot nodes --all

    이 프로세스에는 15분 이상 걸릴 수 있습니다. 다음 출력은 프로세스가 완료되었음을 나타냅니다. 

    All nodes rebooted

  13. 다음 명령을 실행하여 업데이트 진행 상황을 모니터링합니다. 

    $ oc adm wait-for-stable-cluster

    이 프로세스에는 15분 이상 걸릴 수 있습니다. 다음 출력은 프로세스가 완료되었음을 나타냅니다. 

    All clusteroperators are stable

  14. 다음 명령을 실행하여 결합된 keys.json 파일을 클라우드 공급자에서 업데이트된 keys.json 파일로 교체합니다. 

    $ az storage blob upload \
  --overwrite \
  --account-name ${AZURE_STORAGE_ACCOUNT} \
  --container-name ${AZURE_STORAGE_CONTAINER} \
  --name 'openid/v1/jwks' \
  -f ${TEMPDIR}/jwks.new.json

10.1.4. IBM Cloud 인증 정보 교체
링크 복사

기존 서비스 ID에 대한 API 키를 교체하고 해당 시크릿을 업데이트할 수 있습니다.

사전 요구 사항

  • ccoctl 유틸리티를 구성했습니다.
  • 라이브 OpenShift Container Platform 클러스터에 기존 서비스 ID가 설치되어 있어야 합니다.

프로세스

  • ccoctl 유틸리티를 사용하여 서비스 ID의 API 키를 교체하고 다음 명령을 실행하여 시크릿을 업데이트합니다. 

    $ ccoctl <provider_name> refresh-keys \
    1 
    
    --kubeconfig <openshift_kubeconfig_file> \
    2 
    
    --credentials-requests-dir <path_to_credential_requests_directory> \
    3 
    
    --name <name>
    4
    1
    공급자의 이름입니다. 예: ibmcloud 또는 powervs.
    2
    클러스터와 관련된 kubeconfig 파일입니다. 예를 들면 <installation_directory>/auth/kubeconfig입니다.
    3
    인증 정보 요청이 저장되는 디렉터리입니다.
    4
    OpenShift Container Platform 클러스터의 이름입니다.
    참고

    클러스터에서 TechPreviewNoUpgrade 기능 세트에서 활성화한 기술 프리뷰 기능을 사용하는 경우 --enable-tech-preview 매개변수를 포함해야 합니다.

Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2026 Red Hat맨 위로 이동