Meningkatkan batas kebijakan retensi

Di Google Distributed Cloud (GDC) dengan air gap, ada batasan yang mencegah pengguna melampaui kebijakan retensi maksimum yang ditetapkan GDCHRestrictAttributeRange. Batasan ini diterapkan pada CR Bucket di Cluster Admin Org oleh Pengontrol Kebijakan Anthos Config Management. Artinya, hanya akun layanan sistem, pengguna sistem, dan pengguna dalam grup system:masters yang dapat menghapus finalizer secara default. Prosedur yang diuraikan mencakup cara meningkatkan batas kebijakan retensi pada CR Bucket.

Prasyarat

Buat file KUBECONFIG untuk cluster

Perintah Kubectl memerlukan file KUBECONFIG yang valid agar dapat berfungsi. Proses ini memberikan petunjuk langkah demi langkah untuk membuat file KUBECONFIG bagi admin root, admin org, sistem org, dan cluster pengguna.

Prasyarat

Sebelum melanjutkan, pastikan Anda memiliki hal berikut:

  • gdcloud telah diinstal.

  • CLI kubectl telah diinstal.

  • Sertifikat yang ditandatangani oleh Certificate Authority (CA) yang diinstal di workstation.

  • Nama Organisasi.

  • URL Root (GDC). Admin IT OC harus memberi Anda URL root.

Menetapkan variabel lingkungan yang diperlukan

Ikuti petunjuk di bagian ini untuk membuat file KUBECONFIG untuk org-admin, system, atau cluster pengguna mana pun.

  1. Jalankan perintah berikut untuk menentukan variabel lingkungan ORG untuk digunakan nanti di terminal saat ini. ORG adalah nama organisasi Anda.

    export ORG=

  2. Jalankan perintah berikut untuk menentukan variabel lingkungan CONSOLE_URL untuk digunakan nanti di terminal saat ini:

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

    Ganti GDC_URL dengan URL dasar untuk project GDC Anda.

Login ke Cluster

  1. Jalankan perintah berikut untuk login:

    gdcloud auth login --no-browser

  2. Salin perintah gdcloud yang dicetak, dan jalankan di mesin dengan akses browser.

  3. Salin URL yang dicetak dan tempelkan ke kolom URL browser web.

  4. Ikuti petunjuk di halaman web untuk menyelesaikan proses login.

  5. Setelah login berhasil diselesaikan, browser akan menampilkan pesan Authentication successful. Tutup jendela ini.

  6. Ikuti petunjuk di terminal. Setelah berhasil login, terminal akan menampilkan pesan You are now logged in.

Buat file KUBECONFIG

  1. Jalankan perintah berikut untuk menentukan variabel lingkungan CLUSTER untuk digunakan nanti di terminal saat ini. CLUSTER adalah nama cluster yang diinginkan.

    export CLUSTER=

    Lihat tabel berikut untuk mendapatkan nama cluster dengan mengganti ORGANIZATION-NAME dan CLUSTER-NAME dengan nilai yang sesuai:

    Cluster Nama Cluster
    admin root admin-root
    admin org ORGANIZATION-NAME-admin
    sistem org Sistem ORGANIZATION-NAME
    pengguna CLUSTER-NAME

    Anda akan melihat bahwa setiap nama mewakili hal berikut:

    • Nama cluster admin root adalah root-admin.
    • Nama cluster sistem org dan admin org untuk organisasi bernama amira masing-masing adalah amira-admin dan amira-system.
    • Nama cluster untuk cluster pengguna adalah nama clusternya.

  2. Jalankan perintah berikut untuk membuat file KUBECONFIG dan memvalidasi kredensial: 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" Perintah akan menampilkan output berikut:

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

Mendapatkan Peran Admin Kebijakan di cluster

Proses ini membantu Anda mendapatkan akses yang ditingkatkan sementara ke cluster.

Prasyarat

Sebelum melanjutkan, pastikan Anda memiliki hal berikut:

  • IO lain untuk bertindak sebagai Pemberi Persetujuan Permintaan GitLab. IO harus memiliki izin untuk menyetujui permintaan GitLab.
  • Nama cluster yang aksesnya Anda butuhkan. Misalnya: root-admin, org-1-admin.
  • Jenis peran yang ingin Anda ambil. Misalnya: Role ClusterRole, ProjectRole, atau OrganizationRole.
  • Peran yang ingin Anda ambil.
  • Namespace akses yang diperlukan. Tidak diperlukan untuk ClusterRole dan OrganizationRole.
  • Akses ke workstation IT OC.
  • Kredensial untuk GitLab.

Jalankan elevated-access-script

  1. Dari direktori private-cloud/operations/tools/ di workstation Anda, jalankan skrip elevated-access-script.sh.

  2. Jawab pertanyaan "Please enter the GDCH_URL of the cluster..." dengan $GDCH_URL.

  3. Jawab pertanyaan "Enter Gitlab username:" dengan nama pengguna yang Anda gunakan untuk login ke Gitlab.

  4. Untuk pertanyaan "Enter Gitlab personal access token:", masukkan Personal Access Token akun Anda. Untuk membuat Token Akses Pribadi, ikuti petunjuk berikut:

    1. Buka https://gitlab.$GDCH_URL/gdch/iac. Login ke akun IO Gitlab Anda.

    2. Pilih avatar Anda.

    3. Pilih Edit profil.

    4. Di menu navigasi, pilih Token Akses.

    5. Masukkan nama dan tanggal habis masa berlaku untuk token.

    6. Pilih cakupan yang diinginkan.

    7. Pilih Buat token akses pribadi.

  5. Skrip kini akan meng-clone repositori iac ke direktori lokal Anda.

  6. Jawab pertanyaan "Masukkan awalan IdP Anda". IdP Prefix adalah prefiks khusus untuk setiap Penyedia Identitas yang ditambahkan sebelum setiap nama pengguna dalam cluster GDC. Awalan ini dapat ditemukan dengan:

    • berkonsultasi dengan Watch Commander Anda
    • mengambil petunjuk dari Penyiapan GDC, khususnya bagian "Identity and access management" dalam Panduan Pengguna Operator.

    Bentuk awalan yang biasa adalah sekumpulan kata yang diikuti dengan pembatas, yaitu gdch-infra-operator-.

  7. Jawab pertanyaan "Masukkan nama pengguna Anda" dengan nama pengguna yang Anda gunakan untuk login ke Penyedia Identitas Anda.

  8. Jawab pertanyaan "Masukkan cluster yang Anda butuhkan perannya" dengan nama Cluster yang Anda butuhkan perannya.

  9. Skrip akan meminta Anda memilih jenis peran Kubernetes. Ketik jenis peran yang Anda minta.

  10. Jawab pertanyaan "Masukkan peran yang perlu Anda ambil alih" dengan nama peran.

  11. Masukkan durasi akses peran. Durasi akses yang direkomendasikan adalah 3 jam.

  12. Skrip akan menghasilkan tiga file YAML.

    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

    Konfirmasi bahwa setiap file sudah benar dengan menekan Y, atau tekan N untuk mengedit file di vim.

  13. Setelah mengonfirmasi semua file, skrip akan mengirimkan file ini ke cabang elevated_access di GitLab dan membuat permintaan penggabungan.

Meninjau dan menyetujui permintaan akses yang ditingkatkan

Daftar berikut menentukan tindakan yang dilakukan untuk permintaan akses yang ditingkatkan untuk peninjauan dan persetujuan:

  1. IO lain meninjau permintaan GitLab termasuk file konfigurasi kebijakan untuk menyetujui permintaan dengan tepat.
  2. Setelah IO menyetujui permintaan, sistem akan memberikan akses selama jangka waktu yang diminta.
  3. Sistem mencabut akses setelah waktu habis masa berlaku yang ditetapkan.

Batasan patch

Setelah mendapatkan akses yang diperlukan, jalankan perintah berikut untuk menetapkan nilai maksimum Kebijakan retensi bucket yang baru. Contoh ini menunjukkan maksimum baru 120 hari, tetapi pastikan untuk memperbarui perintah ke nilai yang diminta oleh Administrator Platform (PA) Anda:

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

Outputnya akan terlihat seperti berikut ini:

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