Verifikasi identitas dan kontrol akses - Container Service for Kubernetes

Sistem verifikasi identitas dan kontrol akses menyediakan fitur autentikasi dan otorisasi. Autentikasi digunakan untuk memverifikasi identitas pengguna saat mengakses kluster, sedangkan otorisasi digunakan untuk memberikan izin kepada pengguna agar dapat mengakses resource dalam kluster.

Autentikasi dan otorisasi di kluster ACK

Kubernetes menggunakan sertifikat X.509, token bearer, proxy autentikasi, atau protokol OpenID Connect (OIDC) untuk mengautentikasi permintaan API. Untuk informasi selengkapnya tentang metode default yang digunakan untuk mengakses kluster Container Service for Kubernetes (ACK), lihat client certificates dan service account tokens.

Anda dapat memperoleh file kubeconfig yang berisi client certificate melalui Konsol ACK atau dengan memanggil API ACK. Untuk informasi selengkapnya, lihat Kueri file kubeconfig kluster.

Mekanisme otorisasi ACK terdiri dari otorisasi Resource Access Management (RAM) dan otorisasi role-based access control (RBAC). Jika Anda ingin memodifikasi konfigurasi kluster, melakukan scaling kluster, atau menambahkan node ke kluster sebagai RAM user, Anda harus melakukan otorisasi RAM. Otorisasi RAM memungkinkan Anda menyambungkan kebijakan sistem atau kebijakan kustom ke RAM user. Jika Anda ingin mengelola resource Kubernetes di kluster menggunakan RAM user, buka halaman Authorizations di ACK console dan berikan izin berbasis cakupan resource kepada RAM user tersebut, seperti izin untuk melihat informasi pod dan node. Untuk informasi selengkapnya, lihat Ikhtisar otorisasi.

Use a temporary kubeconfig file for authentication when you access the Kubernetes API server of a cluster
File kubeconfig default kluster ACK berisi sertifikat dengan masa berlaku tiga tahun. Jika file kubeconfig tersebut bocor, penyerang dapat menggunakannya untuk mengakses server API Kubernetes kluster. Token service account default merupakan kredensial statis yang berlaku permanen. Jika token service account default bocor, penyerang dapat mengeksploitasinya untuk mendapatkan hak istimewa yang sama dengan service account terkait hingga token tersebut dihapus.
Jika file kubeconfig yang telah dikirimkan bocor, segera cabut file tersebut. Untuk informasi selengkapnya, lihat Cabut file kubeconfig kluster. Untuk informasi lebih lanjut mengenai file kubeconfig kluster ACK, lihat Hasilkan file kubeconfig temporary.
Grant access to Alibaba Cloud resources in compliance with the least privilege principle
Saat memberikan otorisasi kepada pengguna untuk mengakses kluster ACK, jangan berikan izin untuk mengakses resource layanan Alibaba Cloud lainnya. Gunakan otorisasi RAM dan otorisasi RBAC untuk memberikan izin akses ke kluster ACK kepada pengguna.
Create RoleBindings and ClusterRoleBindings in compliance with the least privilege principle
Buat RoleBindings dan ClusterRoleBindings sesuai prinsip hak istimewa minimal. Saat mendefinisikan Role atau ClusterRole, tentukan tindakan yang diperlukan alih-alih menggunakan ["*"] pada bidang Verbs. Jika kesulitan menentukan izin yang harus diberikan, gunakan alat seperti audit2rbac untuk membantu membuat role dan role bindings. Alat ini dapat menghasilkan role dan role bindings yang mencakup semua operasi API yang tercatat dalam log audit Kubernetes.
Limit access to the endpoint of an ACK cluster
Secara default, titik akhir kluster ACK hanya dapat diakses dari dalam kluster dan virtual private cloud (VPC) tempat kluster tersebut ditempatkan. Untuk informasi selengkapnya tentang cara mengaktifkan akses Internet untuk Services dan mengontrol akses ke titik akhir, lihat Tambahkan anotasi ke file YAML Service untuk mengonfigurasi instance CLB.
Audit the permissions of users on a regular basis
Izin yang dimiliki pengguna terhadap kluster dapat berubah seiring waktu. Administrator keamanan dan insinyur O&M kluster harus secara berkala memeriksa izin RAM dan izin RBAC setiap RAM user serta memastikan bahwa hanya izin yang diperlukan yang diberikan. Mereka juga dapat menggunakan alat open source untuk memeriksa izin RBAC yang diberikan kepada service account, pengguna, atau kelompok, serta mencabut izin yang tidak diperlukan. Untuk informasi selengkapnya, lihat kubectl-who-can dan rbac-lookup.

Autentikasi Pod

Di kluster Kubernetes, beberapa aplikasi dan program memerlukan izin untuk memanggil operasi API Kubernetes. Di kluster ACK, cloud controller manager (CCM) memerlukan izin untuk menambah, menghapus, memodifikasi, dan mengkueri node.

Kubernetes Service Accounts
Service account dapat digunakan untuk menetapkan role RBAC ke pod. Kubernetes membuat service account default untuk setiap namespace di kluster. Saat Anda membuat pod tanpa menentukan service account, pod tersebut secara otomatis ditetapkan ke service account default di namespace yang sama. Sebuah Secret yang menyimpan JSON web token (JWT) dipasang ke direktori /var/run/secrets/kubernetes.io/serviceaccount pod sebagai volume. Jika Anda mendekode token tersebut, metadata berikut akan dikembalikan:
```
{
  "iss": "kubernetes/serviceaccount",
  "kubernetes.io/serviceaccount/namespace": "default",
  "kubernetes.io/serviceaccount/secret.name": "default-token-vpc2x",
  "kubernetes.io/serviceaccount/service-account.name": "default",
  "kubernetes.io/serviceaccount/service-account.uid": "1d059c50-0818-4b15-905d-bbf05e1d****",
  "sub": "system:serviceaccount:default:default"
}
```
Service account default memiliki izin berikut terhadap API Kubernetes:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: system:discovery
rules:
- nonResourceURLs:
  - /api
  - /api/*
  - /apis
  - /apis/*
  - /healthz
  - /openapi
  - /openapi/*
  - /version
  - /version/
  verbs:
  - get
```
Role ini dapat digunakan untuk memberikan izin kepada pengguna terautentikasi maupun tidak terautentikasi agar dapat membaca informasi API. Role ini dianggap aman untuk diakses publik.
Saat aplikasi atau program yang berjalan di dalam pod memanggil API Kubernetes, pod tersebut harus ditetapkan ke service account yang memiliki izin yang diperlukan. Izin yang didefinisikan dalam Role atau ClusterRole yang terkait dengan service account tersebut harus dibatasi hanya pada resource API yang perlu diakses oleh pod dan metode yang perlu digunakan oleh pod, sesuai prinsip hak istimewa minimal. Untuk menggunakan service account non-default, atur bidang spec.serviceAccountName dalam konfigurasi pod ke nama service account yang ingin Anda gunakan. Untuk informasi selengkapnya tentang cara membuat service account, lihat ServiceAccount permissions.
Enable service account token volume projection
ACK menyediakan fitur proyeksi volume token service account untuk mengurangi risiko keamanan saat pod menggunakan service account untuk mengakses server API Kubernetes. Fitur ini memungkinkan kubelet meminta dan menyimpan token atas nama pod, serta mengonfigurasi properti token seperti audience dan periode validitas. Jika token telah ada lebih dari 24 jam atau sisa masa berlakunya tinggal 20% atau kurang, kubelet secara otomatis memutar token tersebut. Untuk informasi selengkapnya, lihat Aktifkan proyeksi volume token service account.
Limit access to instance metadata
Metadata instans Elastic Compute Service (ECS) berisi informasi tentang instans ECS di Alibaba Cloud. Anda dapat melihat metadata instans yang sedang berjalan serta mengonfigurasi atau mengelola instans berdasarkan metadata tersebut. Metadata instans berisi informasi sensitif, seperti resource cloud yang digunakan dan data pengguna. Jika metadata instans terpapar ke pod yang ditempatkan pada instans tersebut, informasi tersebut dapat dieksploitasi oleh penyerang dalam skenario multi-penyewa. Untuk pod yang tidak perlu mengirimkan permintaan outbound, gunakan kebijakan jaringan untuk melarang pod mengakses meta-server. Blok kode berikut menunjukkan kebijakan jaringan yang memblokir semua permintaan outbound dari pod dengan label yang ditentukan dalam parameter podSelector, sehingga pod yang cocok tidak dapat mengakses meta-server.
```
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-metadata-access
  namespace: example
spec:
  podSelector:
    matchLabels:
      app: myapp
  policyTypes:
  - Egress
  egress: []
```
Untuk informasi selengkapnya, lihat Gunakan kebijakan jaringan di kluster ACK.
Disable automatic mounting of service account tokens for pods
Anda dapat menggunakan salah satu metode berikut untuk menonaktifkan pemasangan otomatis token service account untuk pod:
Metode 1: Atur automountServiceAccountToken di PodSpec ke false menggunakan templat YAML berikut:
```
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  serviceAccountName: build-robot
  automountServiceAccountToken: false
  ...
```
Metode 2: Jalankan perintah berikut untuk mengatur parameter automountServiceAccountToken dari service account default di namespace ke false menggunakan patch:
```
kubectl patch serviceaccount default -p $'automountServiceAccountToken: false'
```
Assign a separate service account to each application
Untuk mengaktifkan pengelolaan izin aplikasi secara detail halus, tetapkan service account terpisah untuk setiap aplikasi. Untuk informasi selengkapnya, lihat Configure service accounts for pods.
Run applications as non-root users
Secara default, kontainer dijalankan sebagai pengguna root. Hal ini memungkinkan proses dalam kontainer melakukan operasi baca dan tulis pada data di dalam kontainer, yang melanggar praktik terbaik keamanan. Untuk menjalankan kontainer sebagai pengguna non-root, tambahkan parameter spec.securityContext.runAsUser ke PodSpec dan atur runAsUser ke nilai yang sesuai berdasarkan kebutuhan Anda.
Templat berikut menentukan bahwa semua proses di dalam pod dijalankan dengan ID pengguna yang ditentukan dalam bidang runAsUser:
```
apiVersion: v1
kind: Pod
metadata:
  name: security-test
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
  containers:
  - name: sec-test
    image: busybox
    command: [ "sh", "-c", "sleep 1h" ]
```
Dengan cara ini, proses dalam kontainer tidak dapat mengakses file yang memerlukan hak akses root. Jika Anda menambahkan fsgroup=65534 [Nobody] ke parameter securityContext, proses dalam kontainer diizinkan mengakses file-file tersebut.
```
spec:
  securityContext:
    fsGroup: 65534
```
Grant permissions on Alibaba Cloud resources in compliance with the least privilege principle
Jangan memberikan izin berlebihan kepada RAM user atau RAM role. Konfigurasikan kebijakan RAM sesuai prinsip hak istimewa minimal dan hindari pengaturan yang memberikan izin berlebihan, seperti menentukan ["*"] dalam konten kebijakan.

Autentikasi webhook Authenticator

Jika Anda mengintegrasikan SSO dengan RAM atau menggunakan otorisasi RBAC Kubernetes, disarankan untuk menggunakan ack-ram-authenticator guna mengonfigurasi autentikasi webhook. Untuk informasi selengkapnya, lihat Gunakan ack-ram-authenticator untuk membantu server API di kluster ACK yang dikelola menyelesaikan autentikasi webhook. ack-ram-authenticator memberikan manfaat berikut:

Dalam skenario di mana pengguna mengakses server API dengan role SSO dan Authenticator KubeConfig, log audit server API berisi informasi identitas yang disediakan oleh penyedia identitas perusahaan (IDP). Hal ini memungkinkan server API mengautentikasi permintaan yang dikirim oleh pengguna yang mengasumsikan role yang sama.
ack-ram-authenticator menyediakan metode yang fleksibel dan terkendali untuk menerapkan otorisasi RBAC.
Saat RAM user atau RAM role dihapus, ack-ram-authenticator dapat secara otomatis mencabut Authenticator KubeConfig dari karyawan tersebut.