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

10장. 클라우드 공급자 자격 증명 구성 변경

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

클러스터가 사용하는 클라우드 자격 증명 전략을 확인하려면 클라우드 자격 증명 운영자 모드 결정을 참조하세요.

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

10.1.1. AWS OIDC 바운드 서비스 계정 서명자 키 순환
링크 복사

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

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

중요

OIDC에 바인딩된 서비스 계정 서명자 키를 회전하는 프로세스는 중단이 발생하고 상당한 시간이 걸립니다. 일부 단계는 시간에 따라 달라집니다. 계속하기 전에 다음 사항을 고려하세요.

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

사전 요구 사항

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

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

    • s3:GetObject
    • s3:PutObject
    • s3:PutObjectTagging
    • IAM ID 공급자가 공개 CloudFront 배포 URL을 통해 액세스하는 개인 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 필드에 지정된 클러스터 이름과 일치해야 합니다.
    참고

    귀하의 클러스터는 이 예와 다를 수 있으며, 리소스 이름이 클러스터 이름에서 동일하게 파생되지 않을 수 있습니다. 클러스터에 맞는 올바른 리소스 이름을 지정했는지 확인하세요.

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

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

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

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

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

        출력 예

        <subdomain>.cloudfront.net

        여기서 <하위 도메인> 은 영숫자 문자열입니다.

      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
    us-east-1 과 같은 유효한 AWS 지역을 지정하세요. 이 값은 클러스터가 있는 지역과 일치할 필요는 없습니다.

  6. 다음 명령을 실행하여 keys.json 파일의 이름을 바꾸세요. 

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

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

  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가 새 키를 사용하도록 하려면 다시 시작해야 합니다.

    중요

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

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

    $ 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 클러스터에 대한 Cloud Credential Operator(CCO)가 GCP 워크로드 ID를 사용하여 수동 모드로 작동하도록 구성된 경우 바인딩된 서비스 계정 서명자 키를 순환할 수 있습니다.

키를 회전하려면 클러스터에서 기존 키를 삭제해야 하며, 그러면 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

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

  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가 새 키를 사용하도록 하려면 다시 시작해야 합니다.

    중요

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

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

    $ 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(클라우드 자격 증명 운영자)가 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 유틸리티를 구성했습니다.
  • IBM Cloud에 설치된 라이브 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맨 위로 이동