보관 정책 한도 늘리기

Google Distributed Cloud (GDC) 에어 갭에는 사용자가 설정된 최대 보관 정책 GDCHRestrictAttributeRange을 초과하지 못하도록 제한하는 제약 조건이 있습니다. 이 제약 조건은 Anthos Config Management의 정책 컨트롤러에 의해 조직 관리자 클러스터의 버킷 커스텀 리소스 (CR)에 적용됩니다. 즉, 기본적으로 시스템 서비스 계정, 시스템 사용자, system:masters 그룹 내 사용자만 최종자를 삭제할 수 있습니다. 개요에 설명된 절차에서는 버킷 CR의 보관 정책 한도를 늘리는 방법을 다룹니다.

기본 요건

클러스터의 KUBECONFIG 파일 생성

kubectl 명령어는 작동하려면 유효한 KUBECONFIG 파일이 필요합니다. 이 프로세스에서는 루트 관리자, 조직 관리자, 조직 시스템, 사용자 클러스터의 KUBECONFIG 파일을 생성하는 단계별 안내를 제공합니다.

기본 요건

계속하기 전에 다음 사항을 확인하세요.

  • gdcloud이 설치되어 있습니다.

  • kubectl CLI가 설치되어 있습니다.

  • 워크스테이션에 설치된 인증 기관 (CA) 서명 인증서

  • 조직 이름입니다.

  • (GDC) 루트 URL입니다. OC IT 관리자가 루트 URL을 제공해야 합니다.

필수 환경 변수 설정

이 섹션의 안내에 따라 org-admin, system 또는 사용자 클러스터의 KUBECONFIG 파일을 생성합니다.

  1. 다음 명령어를 실행하여 현재 터미널에서 나중에 사용할 환경 변수 ORG를 정의합니다. ORG은 조직 이름입니다.

    export ORG=
    
  2. 다음 명령어를 실행하여 현재 터미널에서 나중에 사용할 환경 변수 CONSOLE_URL를 정의합니다.

    export CONSOLE_URL=https://console.${ORG:?}.$GDC_URL/
    gdcloud config set core/organization_console_url ${CONSOLE_URL:?}
    

    GDC_URL를 GDC 프로젝트의 기본 URL로 바꿉니다.

클러스터에 로그인

  1. 다음 명령어를 실행하여 로그인합니다.

    gdcloud auth login --no-browser
    
  2. 출력된 gdcloud 명령어를 복사하여 브라우저 액세스 권한이 있는 머신에서 실행합니다.

  3. 인쇄된 URL을 복사하여 웹브라우저의 주소 표시줄에 붙여넣습니다.

  4. 웹페이지의 안내에 따라 로그인 절차를 완료합니다.

  5. 로그인이 완료되면 브라우저에 인증이 완료되었습니다. 이 창을 닫아 주세요.

  6. 터미널에 표시된 안내를 따릅니다. 로그인에 성공하면 터미널에 로그인되었습니다라는 메시지가 표시됩니다.

KUBECONFIG 파일 생성

  1. 다음 명령어를 실행하여 현재 터미널에서 나중에 사용할 환경 변수 CLUSTER를 정의합니다. CLUSTER은 원하는 클러스터 이름입니다.

    export CLUSTER=
    

    다음 표를 참고하여 ORGANIZATION-NAMECLUSTER-NAME을 적절한 값으로 바꿔 클러스터 이름을 도출합니다.

    클러스터 클러스터 이름
    루트 관리자 root-admin
    조직 관리자 ORGANIZATION-NAME-admin
    조직 시스템 조직 이름-시스템
    사용자 CLUSTER-NAME

    각 이름은 다음을 나타냅니다.

    • 루트 관리자 클러스터 이름은 root-admin입니다.
    • amira라는 조직의 조직 관리자 및 조직 시스템 클러스터 이름은 각각 amira-adminamira-system입니다.
    • 사용자 클러스터의 클러스터 이름은 클러스터 이름입니다.
  2. 다음 명령어를 실행하여 KUBECONFIG 파일을 생성하고 사용자 인증 정보를 검증합니다. sh export KUBECONFIG=${HOME}/${CLUSTER:?}-kubeconfig.yaml rm ${KUBECONFIG:?} gdcloud clusters get-credentials ${CLUSTER:?} [[ $(kubectl config current-context) == *${CLUSTER:?}* ]] && echo "Success. Your kubeconfig is at $KUBECONFIG" || echo "Failure" 명령어는 다음 출력을 반환해야 합니다.

    Success. Your kubeconfig is at /usr/local/google/home/iris/kubeconfig-amira-admin.yaml
    

클러스터에서 정책 관리자 역할 획득

이 프로세스를 통해 클러스터에 대한 임시 승격 액세스 권한을 얻을 수 있습니다.

기본 요건

계속하기 전에 다음 사항을 확인하세요.

  • GitLab 요청 승인자 역할을 할 다른 IO IO는 GitLab 요청을 승인할 권한이 있어야 합니다.
  • 액세스해야 하는 클러스터 이름입니다. 예를 들면 다음과 같습니다. root-admin, org-1-admin
  • 사용하려는 역할의 유형입니다. 예를 들면 Role ClusterRole, ProjectRole, OrganizationRole입니다.
  • 사용하려는 역할입니다.
  • 필요한 액세스의 네임스페이스입니다. ClusterRoleOrganizationRole에는 필요하지 않습니다.
  • OC IT 워크스테이션에 액세스할 수 있어야 합니다.
  • GitLab 사용자 인증 정보

관리자 액세스 스크립트 실행

  1. 워크스테이션의 private-cloud/operations/tools/ 디렉터리에서 elevated-access-script.sh 스크립트를 실행합니다.

  2. '클러스터의 GDCH_URL을 입력하세요'라는 질문에 $GDCH_URL로 답합니다.

  3. 'Gitlab 사용자 이름을 입력하세요'라는 질문에 Gitlab에 로그인할 때 사용하는 사용자 이름으로 답변합니다.

  4. 'Gitlab 개인 액세스 토큰을 입력하세요'라는 질문에 계정의 개인 액세스 토큰을 입력합니다. 개인 액세스 토큰을 만들려면 다음 안내를 따르세요.

    1. https://gitlab.$GDCH_URL/gdch/iac 페이지로 이동합니다. IO Gitlab 계정에 로그인합니다.

    2. 아바타를 선택합니다.

    3. 프로필 수정을 선택합니다.

    4. 탐색 메뉴에서 액세스 토큰을 선택합니다.

    5. 토큰의 이름과 만료일을 입력합니다.

    6. 원하는 범위를 선택합니다.

    7. 개인 액세스 토큰 만들기를 선택합니다.

  5. 이제 스크립트가 저장소 iac을 로컬 디렉터리로 클론합니다.

  6. 'IdP 접두사 입력' 질문에 답변합니다. IdP Prefix는 GDC 클러스터 내의 모든 사용자 이름 앞에 추가되는 각 ID 공급업체에 고유한 접두사입니다. 이 접두사는 다음 중 한 가지 방법으로 찾을 수 있습니다.

    • Watch Commander에 문의
    • GDC 설정에서, 특히 운영자 사용자 가이드의 'ID 및 액세스 관리' 섹션에서 안내를 가져옵니다.

    이 접두사의 일반적인 형태는 단어 집합과 구분 기호(예: gdch-infra-operator-)입니다.

  7. '사용자 이름을 입력하세요'라는 질문에 ID 공급업체에 로그인할 때 사용하는 사용자 이름으로 답변합니다.

  8. '역할이 필요한 클러스터를 입력하세요'라는 질문에 역할이 필요한 클러스터의 이름을 입력합니다.

  9. 스크립트에서 Kubernetes 역할 유형을 선택하라는 메시지가 표시됩니다. 요청하는 역할 유형을 입력합니다.

  10. '담당해야 하는 역할을 입력하세요'라는 질문에 역할 이름을 입력합니다.

  11. 역할의 액세스 기간을 입력합니다. 권장 액세스 기간은 3시간입니다.

  12. 스크립트에서 yaml 파일 3개를 생성합니다.

    1. ./iac/infrastructure/zonal/zones/ZONE_NAME/${CLUSTER}/kustomization.yaml
    2. ./iac/infrastructure/zonal/zones/ZONE_NAME/${CLUSTER}/${USER}-bindings/kustomization.yaml
    3. ./iac/infrastructure/zonal/zones/ZONE_NAME/${CLUSTER}/${USER}-bindings/${ROLE}-binding.yaml

    Y를 눌러 각 파일이 올바른지 확인하거나 N를 눌러 vim에서 파일을 수정합니다.

  13. 모든 파일을 확인한 후 스크립트는 이러한 파일을 GitLab의 elevated_access 브랜치에 푸시하고 병합 요청을 만듭니다.

승격된 액세스 권한 요청 검토 및 승인

다음 목록에서는 권한 상승된 액세스 요청을 검토하고 승인할 때 취해지는 조치를 명시합니다.

  1. 다른 IO가 정책 구성 파일을 포함한 GitLab 요청을 검토하여 요청을 적절하게 승인합니다.
  2. IO가 요청을 승인하면 시스템에서 요청된 기간 동안 액세스 권한을 부여합니다.
  3. 시스템은 설정된 만료 시간이 지나면 액세스 권한을 취소합니다.

패치 제약 조건

필요한 액세스 권한을 얻은 후 다음 명령어를 실행하여 새 버킷 보관 정책 최대값을 설정합니다. 이 예에서는 새로운 최대 기간이 120일로 표시되지만, 플랫폼 관리자 (PA)가 요청한 값으로 명령어를 업데이트해야 합니다.

kubectl patch GDCHRestrictAttributeRange restrict-bucket-retention-policy -p '{"spec":{"parameters":{"attributeMaxValue":120}}}' --type=merge

다음과 유사하게 출력됩니다.

gdchrestrictattributerange.constraints.gatekeeper.sh/restrict-bucket-retention-policy patched