Menyiapkan cluster anggota fleet untuk autentikasi LDAP

Dokumen ini menjelaskan cara administrator cluster atau operator aplikasi dapat mengonfigurasi cluster Kubernetes untuk mendukung autentikasi dari penyedia pihak ketiga Lightweight Directory Access Protocol (LDAP), seperti Microsoft Entra ID atau Google LDAP. Untuk mengetahui informasi selengkapnya, lihat Tentang autentikasi menggunakan identitas pihak ketiga.

Batasan

Anda harus menggunakan jenis cluster yang mendukung LDAP .

Sebelum memulai

Instal Google Cloud CLI.
Jika Anda menggunakan penyedia identitas (IdP) eksternal, Anda harus login ke gcloud CLI dengan identitas gabungan Anda terlebih dahulu.
Untuk melakukan inisialisasi gcloud CLI, jalankan perintah berikut:
```
gcloud init
```
Setelah menginisialisasi gcloud CLI, update gcloud CLI dan instal komponen yang diperlukan:
```
gcloud components update
gcloud components install kubectl
```
Pastikan administrator platform Anda telah memberi Anda semua informasi penyedia yang Anda butuhkan. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi penyedia LDAP untuk melakukan autentikasi ke cluster.

Selama penyiapan ini, Anda mungkin perlu merujuk ke dokumentasi untuk server LDAP Anda. Panduan administrator berikut menjelaskan konfigurasi untuk beberapa penyedia LDAP populer, termasuk tempat menemukan informasi yang Anda butuhkan untuk login ke server LDAP dan mengonfigurasi cluster Anda:

Mengisi secret akun layanan LDAP

Cluster Anda memerlukan secret akun layanan untuk melakukan autentikasi ke server LDAP dan mengambil detail pengguna. Autentikasi LDAP mendukung mekanisme berikut:

Autentikasi dasar, tempat Anda menggunakan nama pengguna dan sandi.
Autentikasi sertifikat klien, tempat Anda menggunakan kunci pribadi klien dan sertifikat klien.

Anda atau administrator platform Anda harus memiliki informasi ini tentang penyedia Anda dari langkah-langkah di Mengonfigurasi penyedia LDAP untuk melakukan autentikasi ke cluster. Untuk menyediakan informasi login server LDAP ke cluster, Anda harus membuat Secret Kubernetes yang memiliki detail login LDAP. Contoh berikut menunjukkan cara mengonfigurasi Secret untuk kedua jenis autentikasi. Contoh ini menunjukkan Secret yang diterapkan ke namespace anthos-identity-service.

Berikut adalah contoh konfigurasi Secret autentikasi dasar:

apiVersion: v1
kind: Secret
metadata:
  name: SERVICE_ACCOUNT_SECRET_NAME
  namespace: "anthos-identity-service"
type: kubernetes.io/basic-auth     # Make sure the type is correct
data:
  username: USERNAME  # Use a base64-encoded username
  password: PASSWORD  # Use a base64-encoded password

dengan SERVICE_ACCOUNT_SECRET_NAME adalah nama yang Anda pilih untuk Secret ini. Ganti nilai nama pengguna dan sandi dengan nama pengguna dan sandi yang Anda dapatkan pada langkah sebelumnya. USERNAME adalah nama pengguna berenkode base64 PASSWORD adalah sandi berenkode base64

Berikut adalah contoh konfigurasi Secret sertifikat klien:

apiVersion: v1
kind: Secret
metadata:
  name: SERVICE_ACCOUNT_SECRET_NAME
  namespace: anthos-identity-service
type: kubernetes.io/tls            # Make sure the type is correct
data:
  # the data is abbreviated in this example
  tls.crt: |
       MIIC2DCCAcCgAwIBAgIBATANBgkqh ...
  tls.key: |
       MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ...

Ganti SERVICE_ACCOUNT_SECRET_NAME dengan nama yang Anda pilih untuk Secret ini. Ganti nilai sertifikat dan kunci TLS dengan nilai sertifikat dan kunci berenkode yang Anda dapatkan pada langkah sebelumnya.

Contoh ini menunjukkan secret yang diterapkan ke namespace anthos-identity-service. Secara default, komponen sistem memiliki izin untuk membaca Secret di namespace ini. Untuk menggunakan namespace lain, ubah metadata di secret, lalu tambahkan kebijakan RBAC baru untuk memberikan izin membaca Secret di namespace tersebut ke ServiceAccount default di namespace anthos-identity-service, sebagai berikut:

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: NAMESPACE
  name: ais-secret-reader-role
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get","list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ais-secret-reader-role-binding
  namespace: NAMESPACE
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: ais-secret-reader-role
subjects:
- kind: ServiceAccount
  name: default
  namespace: anthos-identity-service
---

Mengonfigurasi cluster

Untuk mengonfigurasi autentikasi ke cluster menggunakan LDAP, Anda menambahkan informasi berikut ke resource kustom Kubernetes bernama ClientConfig:

Informasi tentang penyedia identitas dan parameter yang diperlukan untuk menampilkan informasi pengguna.
Nama dan namespace Secret yang Anda buat dan terapkan pada langkah sebelumnya, yang memungkinkan cluster melakukan autentikasi ke server LDAP.

Untuk mengonfigurasi cluster, edit ClientConfig default di namespace kube-public:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-public edit clientconfig default

Ganti USER_CLUSTER_KUBECONFIG dengan jalur ke file kubeconfig untuk cluster. Jika ada beberapa konteks dalam kubeconfig, konteks saat ini akan digunakan. Anda mungkin perlu mereset konteks saat ini ke cluster yang benar sebelum menjalankan perintah.

Berikut menunjukkan format untuk konfigurasi ClientConfig:

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
  name: default
  namespace: kube-public
spec:
  authentication:
  - name: NAME
    ldap:
      certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
      connectionType: CONNECTION_TYPE
      host: HOST_NAME
      serviceAccountSecret:
        name: SERVICE_ACCOUNT_SECRET_NAME
        namespace: NAMESPACE
        type: SECRET_FORMAT
      user:
        baseDN: BASE_DN
        filter: FILTER
        identifierAttribute: IDENTIFIER_ATTRIBUTE
        loginAttribute: LOGIN_ATTRIBUTE
      group:
        baseDN: BASE_DN
        filter: FILTER
        identifierAttribute: IDENTIFIER_ATTRIBUTE

Anda dapat menambahkan beberapa konfigurasi penyedia identitas OIDC, LDAP, dan SAML ke ClientConfig yang sama. Cluster mencoba melakukan autentikasi dengan setiap konfigurasi dalam urutan konfigurasi tersebut ditentukan, dan berhenti setelah autentikasi pertama berhasil. Contoh ClientConfig berikut menentukan beberapa penyedia identitas dalam urutan tertentu:

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
  name: default
  namespace: kube-public
spec:
  authentication:
  - aws:
      region: us-west-2
    name: AWS Login
  - ldap:
  # Multiple lines are omitted here.
  - saml:
  # Multiple lines are omitted here.
  - azureAD:
  # Multiple lines are omitted here.
  - oidc:
    name: Okta OIDC
  # Multiple lines are omitted here.
  - oidc:
    name: Google OIDC
  # Multiple lines are omitted here.

Kolom LDAP ClientConfig

Tabel berikut menjelaskan kolom objek ldap ClientConfig. Kolom yang perlu Anda tambahkan bergantung pada token penyedia identitas Anda dan cara administrator platform Anda mengonfigurasi penyedia.

Kolom	Diperlukan	Deskripsi	Format
nama	ya	Nama untuk mengidentifikasi konfigurasi LDAP ini	string
host	ya	Nama host atau alamat IP server LDAP. Port bersifat opsional dan akan ditetapkan secara default ke 389, jika tidak ditentukan. Misalnya, `ldap.server.example.com` atau `10.10.10.10:389`.	string
certificateAuthorityData	Diperlukan untuk jenis koneksi LDAP tertentu	Berisi sertifikat otoritas sertifikat berenkode Base64 dan berformat PEM untuk server LDAP. Sertifikat ini hanya boleh diberikan untuk koneksi `ldaps` dan `startTLS`.	string
connectionType	ya	Jenis koneksi LDAP yang akan digunakan saat terhubung ke server LDAP. Nilai defaultnya adalah `startTLS`. Mode `insecure` hanya boleh digunakan untuk pengembangan, karena semua komunikasi dengan server akan berupa teks biasa.	string
serviceAccountSecret
nama	ya	Nama Secret Kubernetes yang menyimpan kredensial untuk akun layanan LDAP.	string
namespace	ya	Namespace Secret Kubernetes yang menyimpan kredensial untuk akun layanan LDAP.	string
jenis	ya	Menentukan format secret akun layanan untuk mendukung berbagai jenis secret. Jika Anda menentukan `basic-auth` dalam konfigurasi Secret, kolom ini harus berupa `basic`, jika tidak, kolom ini harus berupa `tls`. Jika tidak ditentukan, nilai defaultnya adalah `basic`.	string
pengguna
baseDN	ya	Lokasi subtree di direktori LDAP untuk menelusuri entri pengguna.	string
filter	tidak	Filter opsional yang akan diterapkan saat menelusuri pengguna. Filter ini dapat digunakan untuk membatasi lebih lanjut akun pengguna yang diizinkan untuk login. Jika tidak ditentukan, nilai defaultnya adalah `(objectClass=User)`.	string
identifierAttribute	tidak	Menentukan atribut mana yang akan digunakan sebagai identitas pengguna setelah pengguna diautentikasi. Kolom ini berbeda dengan kolom loginAttribute untuk memungkinkan pengguna login dengan nama pengguna, tetapi kemudian memiliki ID sebenarnya berupa alamat email atau Nama yang Dibedakan (DN) lengkap. Misalnya, menetapkan loginAttribute ke `sAMAccountName` dan identifierAttribute ke `userPrincipalName` akan memungkinkan pengguna login sebagai `bsmith`, tetapi kebijakan RBAC sebenarnya untuk pengguna akan ditulis sebagai `bsmith@example.com`. Sebaiknya gunakan `userPrincipalName` karena ini akan unik untuk setiap pengguna. Jika tidak ditentukan, nilai defaultnya adalah `userPrincipalName`.	string
loginAttribute	tidak	Nama atribut yang cocok dengan nama pengguna input. Kolom ini digunakan untuk menemukan pengguna di database LDAP, misalnya `(<LoginAttribute>=<username>)` dan digabungkan dengan kolom filter opsional. Nilai defaultnya adalah `userPrincipalName`.	string
grup (Kolom opsional)
baseDN	ya	Lokasi subtree di direktori LDAP untuk menelusuri entri grup.	string
filter	tidak	Filter opsional yang akan digunakan saat menelusuri grup yang diikuti pengguna. Filter ini dapat digunakan untuk mencocokkan secara eksplisit hanya grup tertentu guna mengurangi jumlah grup yang ditampilkan untuk setiap pengguna. Nilai defaultnya adalah `(objectClass=Group)`.	string
identifierAttribute	tidak	Nama identifikasi setiap grup yang diikuti pengguna. Misalnya, jika kolom ini ditetapkan ke `distinguishedName`, RBAC dan ekspektasi grup lainnya harus ditulis sebagai DN lengkap. Jika tidak ditentukan, nilai defaultnya adalah `distinguishedName`.	string

Apa langkah selanjutnya?

Setelah konfigurasi diterapkan, lanjutkan untuk menyiapkan akses pengguna dari penyedia eksternal ke cluster.

Menyiapkan cluster anggota fleet untuk autentikasi LDAP Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.