Dokumen ini menjelaskan cara administrator cluster atau operator aplikasi dapat mengonfigurasi cluster Kubernetes untuk mendukung autentikasi dari penyedia Lightweight Directory Access Protocol (LDAP) pihak ketiga, 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
-
Install the 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 melakukan inisialisasi 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 mengautentikasi ke cluster.
Selama penyiapan ini, Anda mungkin perlu melihat 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:
Isi rahasia akun layanan LDAP
Cluster Anda memerlukan rahasia 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.
- Otentikasi sertifikat klien, tempat Anda menggunakan kunci pribadi klien dan sertifikat klien.
Anda atau administrator platform Anda harus memiliki informasi ini tentang penyedia Anda dari mengikuti Mengonfigurasi penyedia LDAP untuk mengautentikasi ke cluster.
Agar informasi login server LDAP tersedia untuk cluster, Anda perlu membuat Kubernetes Secret yang memiliki detail login LDAP.
Contoh berikut menunjukkan cara mengonfigurasi Secret untuk kedua jenis autentikasi. Contoh 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 di 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 telah Anda pilih untuk Secret ini. Ganti nilai sertifikat dan kunci TLS dengan nilai sertifikat dan kunci yang dienkode yang Anda dapatkan di langkah sebelumnya.
Contoh 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 di langkah sebelumnya, yang memungkinkan cluster melakukan autentikasi ke server LDAP.
Untuk mengonfigurasi cluster, edit default ClientConfig 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 mengautentikasi dengan setiap konfigurasi dalam urutan yang 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 ClientConfig ldap. Kolom yang perlu Anda tambahkan bergantung pada token penyedia identitas 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 ke 389 secara default, 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 berformat PEM yang dienkode Base64 untuk server LDAP. 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 dilakukan dalam 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, nilainya harus basic, jika tidak, nilainya harus tls. Jika tidak ditentukan, setelan 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. Hal ini dapat digunakan untuk lebih membatasi akun pengguna yang diizinkan untuk login. Jika tidak ditentukan, setelan defaultnya adalah (objectClass=User).
|
string |
| identifierAttribute | tidak | Menentukan atribut mana yang akan digunakan sebagai identitas pengguna setelah pengguna diautentikasi.
Hal ini berbeda dengan kolom loginAttribute untuk
memungkinkan pengguna login dengan nama pengguna, tetapi
ID sebenarnya adalah alamat email atau Nama yang Dibedakan (DN)
lengkap. Misalnya, menyetel 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
akan unik untuk setiap pengguna. Jika tidak ditentukan, nilai defaultnya adalah userPrincipalName.
|
string |
| loginAttribute | tidak | Nama atribut yang cocok dengan nama pengguna input. Atribut 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 subpohon di direktori LDAP untuk menelusuri entri grup. | string |
| filter | tidak | Filter opsional yang akan digunakan saat menelusuri grup tempat pengguna bergabung. Hal 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 mencakup pengguna. Misalnya, jika setelan 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 menyiapkan akses pengguna dari penyedia eksternal ke cluster.