kubectl을 사용하여 구성 동기화 수동 설치(권장하지 않음)

SSH 키 쌍

SSH 키 쌍은 공개 키 파일과 비공개 키 파일로 구성됩니다. 일반적으로 공개 키에는 .pub 확장자가 있습니다.

SSH 키 쌍을 사용하려면 다음 단계를 완료하세요.

1. 구성 동기화가 Git 저장소에 인증할 수 있도록 SSH 키 쌍을 만듭니다. 이 단계는 저장소를 클론하거나 읽기 위해 저장소에 인증해야 할 때 필요합니다. 보안 관리자가 키 쌍을 제공하는 경우에는 이 단계를 건너뛰세요. 보안 및 규정 준수 요구사항에 따라 모든 클러스터에 단일 키 쌍을 사용하거나 클러스터별로 키 쌍을 사용할 수 있습니다.

   다음 명령어는 4096비트 RSA 키를 만듭니다. 이보다 낮은 값은 권장되지 않습니다.

   ssh-keygen -t rsa -b 4096 \
   -C "GIT_REPOSITORY_USERNAME" \
   -N '' \
   -f /path/to/KEYPAIR_FILENAME
   

   다음을 바꿉니다.

   • GIT_REPOSITORY_USERNAME: 구성 동기화가 저장소에 인증하기 위해 사용할 사용자 이름입니다.
   • /path/to/KEYPAIR_FILENAME: 키 쌍의 경로입니다.

   GitHub와 같은 타사 Git 저장소 호스트를 사용하거나 Cloud Source Repositories에서 서비스 계정을 사용하려는 경우 별도의 계정을 사용하는 것이 좋습니다.

2. 저장소가 새로 생성된 공개 키를 인식하도록 구성합니다. Git 호스팅 업체의 문서를 참조하세요. 편의를 위해 다음과 같이 자주 사용되는 Git 호스팅 업체용 안내가 포함되어 있습니다.

   • Cloud Source Repositories
   • Bitbucket
   • GitHub 별도의 배포 키를 만들어 단일 GitHub 저장소에 대한 읽기 전용 액세스 권한을 제공하는 것이 좋습니다.
   • GitLab

3. 클러스터의 새 보안 비밀에 비공개 키를 추가합니다.

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-file=ssh=/path/to/KEYPAIR_PRIVATE_KEY_FILENAME
   

   /path/to/KEYPAIR_PRIVATE_KEY_FILENAME을 비공개 키 이름(.pub 서픽스가 없는 이름)으로 바꿉니다.

4. (권장) SSH 인증을 사용하여 알려진 호스트 확인을 구성하려면 git_creds 보안 비밀의 data.known_hosts 필드에 알려진 호스트 키를 추가하면 됩니다. known_hosts 검사를 중지하려면 보안 비밀에서 known_hosts 필드를 삭제하면 됩니다. 알려진 호스트 키를 추가하려면 다음을 실행하세요.

   kubectl edit secret git-creds \
    --namespace=config-management-system
   

   그런 다음 data에서 알려진 호스트 항목을 추가합니다.

   known_hosts: KNOWN_HOSTS_KEY
   

5. 로컬 디스크에서 비공개 키를 삭제하거나 키를 보호합니다.

6. 구성 동기화를 구성하고 Git 저장소의 URL을 추가할 때 SSH 프로토콜을 사용합니다. Cloud Source Repositories에서 저장소를 사용하는 경우 URL을 입력할 때 다음 형식을 사용해야 합니다.

   ssh://EMAIL@source.developers.google.com:2022/p/PROJECT_ID/r/REPO_NAME
   

   다음을 바꿉니다.

   • EMAIL: Google Cloud 사용자 이름입니다.
   • PROJECT_ID: 저장소가 있는 Google Cloud 프로젝트의 ID입니다.
   • REPO_NAME: 저장소의 이름입니다.

Cookiefile

cookiefile을 획득하는 절차는 저장소 구성에 따라 다릅니다. 예시를 보려면 Cloud Source Repositories 문서의 정적 사용자 인증 정보 생성을 참조하세요. 사용자 인증 정보는 보통 홈 디렉터리의 .gitcookies 파일에 저장되거나 보안 관리자를 통해 제공받을 수 있습니다.

cookiefile을 사용하려면 다음 단계를 완료하세요.

1. cookiefile을 만들고 획득한 후에는 클러스터의 새 보안 비밀에 추가합니다.

   HTTPS 프록시를 사용하지 않는 경우 다음 명령어를 사용하여 보안 비밀을 만듭니다.

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-file=cookie_file=/path/to/COOKIEFILE
   

   HTTPS 프록시를 사용해야 할 경우 다음 명령어를 실행해서 cookiefile과 함께 보안 비밀에 추가합니다.

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-file=cookie_file=/path/to/COOKIEFILE \
    --from-literal=https_proxy=HTTPS_PROXY_URL
   

   다음을 바꿉니다.

   • /path/to/COOKIEFILE: 적절한 경로 및 파일 이름입니다.
   • HTTPS_PROXY_URL: Git 저장소와 통신할 때 사용하는 HTTPS 프록시의 URL입니다.

2. cookiefile 콘텐츠가 로컬에서 계속 필요하면 이 콘텐츠를 보호합니다. 그렇지 않으면 삭제합니다.

토큰

조직에서 SSH 키 사용을 허용하지 않으면 토큰을 대신 사용하는 것이 좋습니다. 구성 동기화를 사용하면 GitHub의 개인 액세스 토큰(PAT), GiLab의 PAT 또는 배포 키, Bitbucket의 앱 비밀번호를 토큰으로 사용할 수 있습니다.

토큰을 사용하여 보안 비밀을 만들려면 다음 단계를 완료합니다.

1. GitHub, GitLab, Bitbucket을 사용하여 토큰을 만듭니다.

   • GitHub: PAT를 만듭니다. 비공개 저장소에서 읽을 수 있도록 토큰에 repo 범위를 부여합니다. PAT를 GitHub 계정에 결합하므로 머신 사용자를 만들고 PAT를 머신 사용자에게 결합하는 것도 좋습니다.
   • GitLab: PAT를 만들거나 배포 토큰을 만듭니다.
   • Bitbucket: 앱 비밀번호를 만듭니다.

2. 토큰을 만들고 얻은 후에는 클러스터의 새 보안 비밀에 추가합니다.

   HTTPS 프록시를 사용하지 않는 경우 다음 명령어를 사용하여 보안 비밀을 만듭니다.

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
     --namespace="config-management-system" \
     --from-literal=username=USERNAME \
     --from-literal=token=TOKEN
   

   다음을 바꿉니다.

   • USERNAME: 사용할 사용자 이름입니다.
   • TOKEN: 이전 단계에서 만든 토큰입니다.

   HTTPS 프록시를 사용해야 할 경우 다음 명령어를 실행해서 username 및 token과 함께 보안 비밀에 추가합니다.

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-literal=username=USERNAME \
     --from-literal=token=TOKEN \
    --from-literal=https_proxy=HTTPS_PROXY_URL
   

   다음을 바꿉니다.

   • USERNAME: 사용할 사용자 이름입니다.
   • TOKEN: 이전 단계에서 만든 토큰입니다.
   • HTTPS_PROXY_URL: Git 저장소와 통신할 때 사용하는 HTTPS 프록시의 URL입니다.

3. 토큰이 로컬에서 계속 필요하면 토큰을 보호합니다. 그렇지 않으면 삭제합니다.

Google 서비스 계정

저장소가 Cloud Source Repositories에 있고 클러스터에서 GKE용 GKE 워크로드 아이덴티티 제휴 또는 GKE용 Fleet 워크로드 아이덴티티 제휴를 사용하는 경우 Google 서비스 계정을 사용하여 구성 동기화에 관리형 클러스터와 동일한 프로젝트에 있는 저장소에 대한 액세스 권한을 부여할 수 있습니다.

1. 아직 서비스 계정이 없으면 서비스 계정을 만듭니다.

2. Cloud Source Repositories 리더(roles/source.reader) IAM 역할을 Google 서비스 계정에 부여합니다. Cloud Source Repositories 역할 및 권한에 대한 자세한 내용은 저장소를 볼 수 있는 권한 부여를 참조하세요.

   • 프로젝트의 모든 저장소에 동일한 권한이 적용되는 경우 프로젝트 전체 권한을 부여합니다.

     gcloud projects add-iam-policy-binding PROJECT_ID \
       --role=roles/source.reader \
       --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
     

   • 서비스 계정이 프로젝트의 저장소마다 다른 수준의 액세스 권한을 갖도록 하려면 저장소별 권한을 부여합니다.

     gcloud source repos set-iam-policy REPOSITORY POLICY_FILE --project=PROJECT_ID
     

3. Google Cloud 콘솔을 사용하여 구성 동기화를 구성하는 경우 GKE용 워크로드 아이덴티티 제휴를 인증 유형으로 선택한 후 서비스 계정 이메일을 추가합니다.

   Google Cloud CLI를 사용하여 구성 동기화를 구성하는 경우 gcpserviceaccount를 secretType으로 추가한 후 서비스 계정 이메일을 gcpServiceAccountEmail에 추가합니다.

4. 구성 동기화를 구성한 후, Kubernetes 서비스 계정과 Google 서비스 계정 간에 IAM 정책 바인딩을 만듭니다. 구성 동기화를 처음 구성할 때까지는 Kubernetes 서비스 계정이 생성되지 않습니다.

   Fleet에 등록된 클러스터를 사용하는 경우 Fleet당 한 번만 정책 바인딩을 만들면 됩니다. Fleet에 등록된 모든 클러스터는 같은 GKE용 워크로드 아이덴티티 제휴 풀을 공유합니다. Fleet의 동일성 개념에 따라 IAM 정책을 한 클러스터의 Kubernetes 서비스 계정에 추가하면 동일한 Fleet에 있는 다른 클러스터의 동일한 네임스페이스에 있는 Kubernetes 서비스 계정도 동일한 IAM 정책을 받습니다.

   이 바인딩을 사용하면 구성 동기화 Kubernetes 서비스 계정이 Google 서비스 계정 역할을 합니다.

   gcloud iam service-accounts add-iam-policy-binding \
       GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/iam.workloadIdentityUser \
       --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
       --project=PROJECT_ID
   

다음을 바꿉니다.

• PROJECT_ID: 조직의 프로젝트 ID입니다.
• FLEET_HOST_PROJECT_ID: GKE용 GKE 워크로드 아이덴티티 제휴를 사용하는 경우 PROJECT_ID와 동일합니다. GKE용 Fleet 워크로드 아이덴티티 제휴를 사용하는 경우 클러스터가 등록된 Fleet의 프로젝트 ID입니다.
• GSA_NAME: Artifact Registry에 연결하는 데 사용할 커스텀 Google 서비스 계정입니다. 서비스 계정에는 Artifact Registry 리더(roles/artifactregistry.reader) IAM 역할이 있어야 합니다.
• KSA_NAME: 조정자의 Kubernetes 서비스 계정입니다.
  • 루트 저장소의 경우 RootSync 이름이 root-sync이면 root-reconciler를 사용합니다. 그렇지 않은 경우 root-reconciler-ROOT_SYNC_NAME을 사용하세요. Google Cloud 콘솔 또는 Google Cloud CLI를 사용하여 구성 동기화를 설치하면 구성 동기화는 root-sync라는 RootSync 객체를 자동으로 만듭니다.
• REPOSITORY: 저장소의 이름입니다.
• POLICY_FILE: Identity and Access Management 정책이 포함된 JSON 또는 YAML 파일입니다.

Compute Engine 기본 서비스 계정

저장소가 Cloud Source Repositories에 있고 클러스터가 GKE용 워크로드 아이덴티티 제휴가 중지된 GKE이면 gcenode를 인증 유형으로 사용할 수 있습니다.

Google Cloud 콘솔을 사용하여 구성 동기화를 구성하는 경우 Google Cloud Repository를 인증 유형으로 선택합니다.

Google Cloud CLI를 사용하여 구성 동기화를 구성하는 경우 gcenode를 secretType으로 추가하세요.

Google Cloud Repository 또는 gcenode를 선택하면 Compute Engine 기본 서비스 계정을 사용할 수 있습니다. Compute Engine 기본 서비스 계정에 Cloud Source Repositories 리더(roles/source.reader) IAM 역할을 부여해야 합니다. Cloud Source Repositories 역할 및 권한에 대한 자세한 내용은 저장소를 볼 수 있는 권한 부여를 참조하세요.

gcloud projects add-iam-policy-binding PROJECT_ID \
  --role=roles/source.reader \
  --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com"

PROJECT_ID를 조직의 프로젝트 ID로 바꾸고 PROJECT_NUMBER를 조직의 프로젝트 번호로 바꿉니다.

Kubernetes 서비스 계정

Artifact Registry에 OCI 이미지를 저장하고 클러스터에서 GKE용 GKE 워크로드 아이덴티티 제휴 또는 GKE용 Fleet 워크로드 아이덴티티 제휴를 사용하는 경우 버전 1.17.2 이상에서 k8sserviceaccount를 인증 유형으로 사용할 수 있습니다. 이 옵션은 간소화된 구성 프로세스로 인해 gcpserviceaccount보다 권장됩니다.

1. GKE용 워크로드 아이덴티티 제휴 풀이 있는 Kubernetes 서비스 계정에 Artifact Registry 리더(roles/artifactregistry.reader) IAM 역할을 부여합니다. Artifact Registry 역할 및 권한에 대한 자세한 내용은 Artifact Registry의 역할 및 권한 구성을 참조하세요.

   • 프로젝트의 모든 저장소에 동일한 권한이 적용되는 경우 프로젝트 전체 권한을 부여합니다.

     gcloud projects add-iam-policy-binding PROJECT_ID \
           --role=roles/artifactregistry.reader \
           --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"
     

   • 서비스 계정이 프로젝트의 저장소마다 다른 수준의 액세스 권한을 갖도록 하려면 저장소별 권한을 부여합니다.

     gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
        --location=LOCATION \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
        --project=PROJECT_ID
     

   다음을 바꿉니다.

   • PROJECT_ID: 조직의 프로젝트 ID입니다.
   • FLEET_HOST_PROJECT_ID: GKE용 GKE 워크로드 아이덴티티 제휴를 사용하는 경우 PROJECT_ID와 동일합니다. GKE용 Fleet 워크로드 아이덴티티 제휴를 사용하는 경우 클러스터가 등록된 Fleet의 프로젝트 ID입니다.
   • KSA_NAME: 조정자의 Kubernetes 서비스 계정입니다.
     • 루트 저장소의 경우 RootSync 이름이 root-sync이면 root-reconciler를 사용합니다. 그렇지 않은 경우 root-reconciler-ROOT_SYNC_NAME을 사용하세요. Google Cloud 콘솔 또는 Google Cloud CLI를 사용하여 구성 동기화를 설치하면 구성 동기화는 root-sync라는 RootSync 객체를 자동으로 만듭니다.
   • REPOSITORY: 저장소 ID입니다.
   • LOCATION: 저장소의 리전 또는 멀티 리전 위치입니다.

Google 서비스 계정

Artifact Registry에 OCI 이미지를 저장하고 클러스터에서 GKE용 GKE 워크로드 아이덴티티 제휴 또는 GKE용 Fleet 워크로드 아이덴티티 제휴를 사용하는 경우 gcpserviceaccount를 인증 유형으로 사용할 수 있습니다. 버전 1.17.2부터는 대신 k8sserviceaccount를 사용하는 것이 좋습니다. 이 옵션을 사용하면 Google 서비스 계정 및 연결된 IAM 정책 바인딩을 만드는 추가 단계가 필요하지 않습니다.

1. 아직 서비스 계정이 없으면 서비스 계정을 만듭니다.

2. Artifact Registry 리더(roles/artifactregistry.reader) IAM 역할을 Google 서비스 계정에 부여합니다. Artifact Registry 역할 및 권한에 대한 자세한 내용은 Artifact Registry의 역할 및 권한 구성을 참조하세요.

   • 프로젝트의 모든 저장소에 동일한 권한이 적용되는 경우 프로젝트 전체 권한을 부여합니다.

     gcloud projects add-iam-policy-binding PROJECT_ID  \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
     

   • 서비스 계정이 프로젝트의 저장소마다 다른 수준의 액세스 권한을 갖도록 하려면 저장소별 권한을 부여합니다.

     gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
        --location=LOCATION \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
        --project=PROJECT_ID
     

3. 다음 명령어를 실행하여 Kubernetes 서비스 계정과 Google 서비스 계정 사이에 IAM 정책 바인딩을 만듭니다.

   gcloud iam service-accounts add-iam-policy-binding
     GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/iam.workloadIdentityUser \
       --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
       --project=PROJECT_ID
   

다음을 바꿉니다.

• PROJECT_ID: 조직의 프로젝트 ID입니다.
• FLEET_HOST_PROJECT_ID: GKE용 GKE 워크로드 아이덴티티 제휴를 사용하는 경우 PROJECT_ID와 동일합니다. GKE용 Fleet 워크로드 아이덴티티 제휴를 사용하는 경우 클러스터가 등록된 Fleet의 프로젝트 ID입니다.
• GSA_NAME: Artifact Registry에 연결하는 데 사용할 커스텀 Google 서비스 계정입니다. 서비스 계정에는 Artifact Registry 리더(roles/artifactregistry.reader) IAM 역할이 있어야 합니다.
• KSA_NAME: 조정자의 Kubernetes 서비스 계정입니다.
  • 루트 저장소의 경우 RootSync 이름이 root-sync이면 root-reconciler를 사용합니다. 그렇지 않은 경우 root-reconciler-ROOT_SYNC_NAME을 사용하세요. Google Cloud 콘솔 또는 Google Cloud CLI를 사용하여 구성 동기화를 설치하면 구성 동기화는 root-sync라는 RootSync 객체를 자동으로 만듭니다.
• REPOSITORY: 저장소 ID입니다.
• LOCATION: 저장소의 리전 또는 멀티 리전 위치입니다.

Compute Engine 기본 서비스 계정

Artifact Registry에 Helm 차트를 저장하고 클러스터가 GKE용 워크로드 아이덴티티 제휴가 중지된 GKE이면 gcenode를 인증 유형으로 사용할 수 있습니다. 구성 동기화는 Compute Engine 기본 서비스 계정을 사용합니다. Compute Engine 기본 서비스 계정에 Artifact Registry에 대한 읽기 액세스를 부여해야 합니다.

1. 다음 명령어를 실행하여 Compute Engine 서비스 계정에 Artifact Registry에 대한 읽기 권한을 부여합니다.

   gcloud projects add-iam-policy-binding PROJECT_ID \
      --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
      --role=roles/artifactregistry.reader
   

   PROJECT_ID를 조직의 프로젝트 ID로 바꾸고 PROJECT_NUMBER를 조직의 프로젝트 번호로 바꿉니다.

RootSync

1. Git 서버의 인증서를 발급하는 데 사용된 CA 인증서를 가져와서 파일에 저장합니다.

2. RootSync 객체의 경우 config-management-system 네임스페이스에 보안 비밀을 만들어야 합니다. 예를 들면 다음과 같습니다.

   kubectl create ns config-management-system && 
   
   kubectl create secret generic ROOT_CA_CERT_SECRET_NAME 
   
    --namespace=config-management-system 
   
    --from-file=cert=/path/to/CA_CERT_FILE
   

3. 작업자를 구성할 때 RootSync 객체의 caCertSecretRef.name 필드 값을 ROOT_CA_CERT_SECRET_NAME으로 설정합니다.

RepoSync

1. Git 서버의 인증서를 발급하는 데 사용된 CA 인증서를 가져와서 파일에 저장합니다.

2. RepoSync 객체의 경우 RepoSync와 동일한 네임스페이스에 보안 비밀을 만들어야 합니다. 예를 들면 다음과 같습니다.

   kubectl create ns REPO_SYNC_NAMESPACE && 
   
   kubectl create secret generic NAMESPACE_CA_CERT_SECRET_NAME 
   
    --namespace=REPO_SYNC_NAMESPACE 
   
    --from-file=cert=/path/to/CA_CERT_FILE
   

3. RepoSync를 구성할 때 RepoSync 객체의 caCertSecretRef.name 필드 값을 NAMESPACE_CA_CERT_SECRET_NAME으로 설정합니다.

토큰

Helm 저장소 사용자 이름과 비밀번호로 보안 비밀을 만듭니다.

kubectl create secret generic SECRET_NAME \
    --namespace=config-management-system \
    --from-literal=username=USERNAME \
    --from-literal=password=PASSWORD

다음을 바꿉니다.

• SECRET_NAME: 보안 비밀에 지정할 이름입니다.
• USERNAME: Helm 저장소 사용자 이름입니다.
• PASSWORD: Helm 저장소 비밀번호입니다.

ConfigManagement Operator를 구성할 때 spec.helm.secretRef.name에 선택한 보안 비밀 이름을 사용합니다.

Kubernetes 서비스 계정

Artifact Registry에 Helm 차트를 저장하고 클러스터에서 GKE용 GKE 워크로드 아이덴티티 제휴 또는 GKE용 Fleet 워크로드 아이덴티티 제휴를 사용하는 경우 버전 1.17.2 이상에서 k8sserviceaccount를 인증 유형으로 사용할 수 있습니다. 이 옵션은 간소화된 구성 프로세스로 인해 gcpserviceaccount보다 권장됩니다.

1. GKE용 워크로드 아이덴티티 제휴 풀이 있는 Kubernetes 서비스 계정에 Artifact Registry 리더(roles/artifactregistry.reader) IAM 역할을 부여합니다. Artifact Registry 역할 및 권한에 대한 자세한 내용은 Artifact Registry의 역할 및 권한 구성을 참조하세요.

   • 프로젝트의 모든 저장소에 동일한 권한이 적용되는 경우 프로젝트 전체 권한을 부여합니다.

     gcloud projects add-iam-policy-binding PROJECT_ID \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"
     

   • 서비스 계정이 프로젝트의 저장소마다 다른 수준의 액세스 권한을 갖도록 하려면 저장소별 권한을 부여합니다.

     gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
        --location=LOCATION \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
        --project=PROJECT_ID
     

   다음을 바꿉니다.

   • PROJECT_ID: 조직의 프로젝트 ID입니다.
   • FLEET_HOST_PROJECT_ID: GKE용 GKE 워크로드 아이덴티티 제휴를 사용하는 경우 PROJECT_ID와 동일합니다. GKE용 Fleet 워크로드 아이덴티티 제휴를 사용하는 경우 클러스터가 등록된 Fleet의 프로젝트 ID입니다.
   • KSA_NAME: 조정자의 Kubernetes 서비스 계정입니다.
     • 루트 저장소의 경우 RootSync 이름이 root-sync이면 root-reconciler를 사용합니다. 그렇지 않은 경우 root-reconciler-ROOT_SYNC_NAME을 사용하세요.
   • REPOSITORY: 저장소 ID입니다.
   • LOCATION: 저장소의 리전 또는 멀티 리전 위치입니다.

Google 서비스 계정

Artifact Registry에 Helm 차트를 저장하고 클러스터에서 GKE용 GKE 워크로드 아이덴티티 제휴 또는 GKE용 Fleet 워크로드 아이덴티티 제휴를 사용하는 경우 gcpserviceaccount를 인증 유형으로 사용할 수 있습니다. 버전 1.17.2부터는 대신 k8sserviceaccount를 사용하는 것이 좋습니다. 이 옵션을 사용하면 Google 서비스 계정 및 연결된 IAM 정책 바인딩을 만드는 추가 단계가 필요하지 않습니다.

1. 아직 서비스 계정이 없으면 서비스 계정을 만듭니다.

2. Artifact Registry 리더(roles/artifactregistry.reader) IAM 역할을 Google 서비스 계정에 부여합니다. Artifact Registry 역할 및 권한에 대한 자세한 내용은 Artifact Registry의 역할 및 권한 구성을 참조하세요.

   • 프로젝트의 모든 저장소에 동일한 권한이 적용되는 경우 프로젝트 전체 권한을 부여합니다.

     gcloud projects add-iam-policy-binding PROJECT_ID  \
           --role=roles/artifactregistry.reader \
           --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
     

   • 서비스 계정이 프로젝트의 저장소마다 다른 수준의 액세스 권한을 갖도록 하려면 저장소별 권한을 부여합니다.

     gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
        --location=LOCATION \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
        --project=PROJECT_ID
     

3. 다음 명령어를 실행하여 Kubernetes 서비스 계정과 Google 서비스 계정 사이에 IAM 정책 바인딩을 만듭니다.

   gcloud iam service-accounts add-iam-policy-binding
     GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/iam.workloadIdentityUser \
       --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"
       --project=PROJECT_ID
   

다음을 바꿉니다.

• PROJECT_ID: 조직의 프로젝트 ID입니다.
• FLEET_HOST_PROJECT_ID: GKE용 GKE 워크로드 아이덴티티 제휴를 사용하는 경우 PROJECT_ID와 동일합니다. GKE용 Fleet 워크로드 아이덴티티 제휴를 사용하는 경우 클러스터가 등록된 Fleet의 프로젝트 ID입니다.
• GSA_NAME: Artifact Registry에 연결하는 데 사용할 커스텀 Google 서비스 계정입니다. 서비스 계정에는 Artifact Registry 리더(roles/artifactregistry.reader) IAM 역할이 있어야 합니다.
• KSA_NAME: 조정자의 Kubernetes 서비스 계정입니다.
  • 루트 저장소의 경우 RootSync 이름이 root-sync이면 root-reconciler를 사용합니다. 그렇지 않은 경우 root-reconciler-ROOT_SYNC_NAME을 사용하세요.
• REPOSITORY: 저장소 ID입니다.
• LOCATION: 저장소의 리전 또는 멀티 리전 위치입니다.

Compute Engine 기본 서비스 계정

Artifact Registry에 Helm 차트를 저장하고 클러스터가 GKE용 워크로드 아이덴티티 제휴가 중지된 GKE이면 gcenode를 인증 유형으로 사용할 수 있습니다. 구성 동기화는 Compute Engine 기본 서비스 계정을 사용합니다. Compute Engine 기본 서비스 계정에 Artifact Registry에 대한 읽기 액세스를 부여해야 합니다. 이미지를 가져올 수 있는 읽기 전용 권한을 부여하려면 storage-ro 액세스 범위를 부여해야 할 수 있습니다.

1. Compute Engine 서비스 계정에 Artifact Registry에 대한 읽기 권한을 부여합니다.

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
       --role=roles/artifactregistry.reader
   

   PROJECT_ID를 조직의 프로젝트 ID로 바꾸고 PROJECT_NUMBER를 조직의 프로젝트 번호로 바꿉니다.