Catatan perev. : Artikel ini ditulis oleh Javier Salmeron, seorang insinyur dari komunitas Kubernetes yang terkenal di Bitnami, dan diterbitkan di blog CNCF pada awal Agustus. Penulis berbicara tentang dasar-dasar mekanisme RBAC (kontrol akses berbasis peran) yang muncul di Kubernetes satu setengah tahun yang lalu. Materi ini akan sangat berguna bagi mereka yang terbiasa dengan perangkat komponen kunci K8 (lihat tautan ke artikel serupa lainnya di bagian akhir).
Geser dari presentasi yang dibuat oleh karyawan Google pada saat peluncuran Kubernetes 1.6Banyak pengguna Kubernet yang berpengalaman mungkin mengingat rilis Kubernetes 1.6, ketika otorisasi berbasis peran berbasis kontrol (RBAC) menjadi beta. Jadi mekanisme otentikasi alternatif muncul, yang melengkapi yang sudah ada, tetapi sulit untuk mengelola dan memahami, Kontrol Akses Berbasis Atribut (ABAC). Semua orang dengan antusias menyambut fitur baru ini, tetapi pada saat yang sama banyak pengguna yang kecewa. StackOverflow dan GitHub dipenuhi dengan laporan pembatasan RBAC karena sebagian besar dokumentasi dan contoh tidak memperhitungkan RBAC (tapi sekarang semuanya baik-baik saja). Contoh referensi adalah Helm: hanya menjalankan
helm init +
helm install tidak lagi berfungsi. Tiba-tiba, kami perlu menambahkan elemen "aneh" seperti
ServiceAccounts atau
RoleBindings sebelum
RoleBindings bahkan menggunakan grafik dengan WordPress atau Redis (lihat
instruksi untuk lebih lanjut tentang ini).
Mengesampingkan upaya pertama yang gagal ini, orang tidak dapat menyangkal kontribusi besar yang dibuat RBAC untuk mengubah Kubernetes menjadi platform yang siap-produksi. Banyak dari kita yang berhasil bermain dengan Kubernetes dengan hak administrator penuh, dan kami sangat memahami bahwa dalam lingkungan nyata diperlukan:
- Untuk memiliki banyak pengguna dengan properti berbeda yang menyediakan mekanisme otentikasi yang diinginkan.
- Memiliki kontrol penuh atas operasi apa yang dapat dilakukan setiap pengguna atau grup pengguna.
- Memiliki kendali penuh atas operasi apa yang dapat dilakukan setiap proses di hati.
- Batasi visibilitas sumber daya tertentu di ruang nama.
Dan dalam hal ini, RBAC adalah elemen kunci yang menyediakan kemampuan yang sangat dibutuhkan. Dalam artikel ini, kami akan dengan cepat membahas dasar-dasarnya
(lihat video ini untuk detailnya; ikuti tautan webinar Bitnami 1 jam dalam Bahasa Inggris - kira - kira. Terjemahan ) . Dan masuk sedikit lebih dalam ke saat-saat yang paling membingungkan.
Kunci untuk memahami RBAC di Kubernetes
Untuk sepenuhnya mewujudkan gagasan RBAC, Anda perlu memahami bahwa tiga elemen terlibat di dalamnya:
- Subjek - serangkaian pengguna dan proses yang ingin memiliki akses ke API Kubernetes;
- Sumber Daya - Kumpulan objek API Kubernetes yang tersedia di sebuah cluster. Contoh mereka (antara lain) adalah Pod , Penyebaran , Layanan , Nodes , PersistentVolumes ;
- Kata kerja (kata kerja) - satu set operasi yang dapat dilakukan pada sumber daya. Ada berbagai kata kerja (dapatkan, tonton, buat, hapus, dll.), Tetapi semuanya pada akhirnya adalah operasi CRUD (Buat, Baca, Perbarui, Hapus).
Dengan ketiga elemen ini dalam pikiran, gagasan utama RBAC adalah:
"Kami ingin menghubungkan subjek, sumber daya API, dan operasi." Dengan kata lain, kami ingin menunjukkan untuk
pengguna tertentu
operasi yang dapat dilakukan pada berbagai
sumber daya .
Memahami Objek RBAC di API
Dengan menggabungkan ketiga jenis entitas ini, objek RBAC yang tersedia di API Kubernetes menjadi jelas:
Roles menghubungkan sumber daya dan kata kerja. Mereka dapat digunakan kembali untuk subjek yang berbeda. Terikat ke satu namespace (kami tidak dapat menggunakan templat yang mewakili lebih dari satu [namespace], tetapi kami dapat menggunakan objek peran yang sama ke ruang nama yang berbeda). Jika Anda ingin menerapkan peran ke seluruh cluster, ada objek ClusterRoles serupa.RoleBindings menghubungkan entitas entitas yang tersisa. Dengan menentukan peran yang sudah mengikat objek API ke kata kerja, kami sekarang memilih subjek yang dapat menggunakannya. Setara dengan tingkat cluster (mis. Tanpa mengikat ruang nama) adalah ClusterRoleBindings .
Dalam contoh di bawah ini, kami memberi pengguna
jsalmeron hak untuk membaca, mendapatkan daftar, dan membuat perapian di ruang nama
tes . Ini berarti
jsalmeron akan dapat menjalankan perintah-perintah ini:
kubectl get pods --namespace test kubectl describe pod --namespace test pod-name kubectl create --namespace test -f pod.yaml
... tapi tidak seperti itu:
kubectl get pods --namespace kube-system
Contoh file YAML:
kind: Role apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: pod-read-create namespace: test rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list", "create"]
kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: salme-pods namespace: test subjects: - kind: User name: jsalmeron apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: pod-read-create apiGroup: rbac.authorization.k8s.io
Hal menarik lainnya adalah ini: sekarang pengguna dapat membuat pod, dapatkah kita membatasi berapa? Ini akan membutuhkan objek lain yang tidak terkait langsung dengan spesifikasi RBAC dan memungkinkan Anda untuk mengkonfigurasi batas sumber daya:
ResourceQuota dan
LimitRanges . Mereka benar-benar layak untuk dieksplorasi ketika mengkonfigurasi komponen cluster yang penting [seperti membuat perapian].
Subjek: Pengguna dan ... ServiceAccounts?
Salah satu kesulitan yang dihadapi banyak pengguna Kubernetes dalam konteks subjek adalah perbedaan antara pengguna biasa dan
ServiceAccounts . Secara teori, semuanya sederhana:
Users - pengguna global, yang dirancang untuk orang atau proses yang tinggal di luar cluster;ServiceAccounts - dibatasi oleh namespace dan dimaksudkan untuk proses dalam cluster yang berjalan di pod.
Kesamaan kedua jenis terletak pada kebutuhan untuk mengotentikasi dengan API untuk melakukan operasi tertentu pada banyak sumber daya, dan bidang subjek mereka terlihat sangat spesifik. Mereka juga dapat menjadi bagian dari grup, jadi
RoleBinding memungkinkan
RoleBinding untuk mengikat lebih dari satu subjek (walaupun hanya satu grup yang diizinkan untuk
ServiceAccounts -
system:serviceaccounts ). Namun, perbedaan utama adalah penyebab sakit kepala: pengguna tidak memiliki objek yang sesuai dengan mereka di API Kubernetes. Ternyata operasi semacam itu ada:
kubectl create serviceaccount test-service-account
... tapi yang ini hilang:
kubectl create user jsalmeron
Situasi ini memiliki konsekuensi serius: jika cluster tidak menyimpan informasi tentang pengguna, administrator harus mengelola akun di luar cluster. Ada berbagai cara untuk memecahkan masalah: sertifikat TLS, token, OAuth2, dll.
Selain itu, Anda perlu membuat konteks
kubectl kami dapat mengakses cluster melalui akun baru ini. Untuk membuat file dengannya, Anda dapat menggunakan perintah
kubectl config (yang tidak memerlukan akses ke API Kubernetes, sehingga dapat dijalankan oleh pengguna mana pun). Video di atas memiliki contoh membuat pengguna dengan sertifikat TLS.
RBAC dalam Penyebaran: Contoh
Kami melihat contoh di mana pengguna tertentu diberikan hak untuk operasi di kluster. Tetapi bagaimana dengan
Penyebaran yang membutuhkan akses ke API Kubernetes? Pertimbangkan skenario tertentu untuk mendapatkan pemahaman yang lebih baik.
Ambil contoh aplikasi infrastruktur populer - RabbitMQ. Kami akan menggunakan
Bitmami Helm Chart untuk RabbitMQ (dari repositori resmi helm / charts), yang menggunakan
wadah bitnami / rabbitmq . Sebuah plugin untuk Kubernetes dibangun ke dalam wadah, yang bertanggung jawab untuk mendeteksi anggota lain dari cluster RabbitMQ. Karena itu, proses di dalam wadah memerlukan akses ke API Kubernetes, dan kita perlu mengonfigurasi
ServiceAccount dengan hak istimewa RBAC yang benar.
Ketika datang ke
ServiceAccounts , ikuti praktik yang baik ini:
- Konfigurasikan
ServiceAccounts untuk setiap Penyebaran dengan
sekumpulan hak minimum .
Untuk aplikasi yang memerlukan akses ke Kubernetes API, Anda mungkin tergoda untuk membuat semacam "
ServiceAccount istimewa" yang dapat melakukan hampir semua hal di cluster. Meskipun ini tampak seperti solusi yang lebih sederhana, ini pada akhirnya dapat mengarah pada kerentanan keamanan yang dapat memungkinkan operasi yang tidak diinginkan. (Video tersebut melihat contoh Tiller [komponen Helm] dan konsekuensi dari memiliki
ServiceAccounts dengan hak istimewa yang luar biasa.)
Selain itu,
Penyebaran yang berbeda akan memiliki kebutuhan yang berbeda dalam hal akses ke API, sehingga masuk akal untuk setiap
Penyebaran untuk memiliki
ServiceAccounts berbeda.
Dengan mengingat hal ini, mari kita lihat konfigurasi RBAC mana yang benar untuk kasus
Deployment dengan RabbitMQ.
Dalam
dokumentasi plugin dan
kode sumbernya, Anda dapat melihat bahwa ia meminta daftar
Endpoint dari API Kubernetes. Ini adalah bagaimana anggota yang tersisa dari kluster RabbitMQ terdeteksi. Oleh karena itu, grafik Bitnami RabbitMQ menciptakan:
- ServiceAccount untuk perapian dengan RabbitMQ:
{{- if .Values.rbacEnabled }} apiVersion: v1 kind: ServiceAccount metadata: name: {{ template "rabbitmq.fullname" . }} labels: app: {{ template "rabbitmq.name" . }} chart: {{ template "rabbitmq.chart" . }} release: "{{ .Release.Name }}" heritage: "{{ .Release.Service }}" {{- end }}
- Peran (kami berasumsi bahwa seluruh kluster RabbitMQ digunakan dalam ruang nama tunggal), yang memungkinkan kata kerja tersebut untuk sumber daya Endpoint :
{{- if .Values.rbacEnabled }} kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: name: {{ template "rabbitmq.fullname" . }}-endpoint-reader labels: app: {{ template "rabbitmq.name" . }} chart: {{ template "rabbitmq.chart" . }} release: "{{ .Release.Name }}" heritage: "{{ .Release.Service }}" rules: - apiGroups: [""] resources: ["endpoints"] verbs: ["get"] {{- end }}
- RoleBinding menghubungkan
ServiceAccount ke peran:
{{- if .Values.rbacEnabled }} kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: {{ template "rabbitmq.fullname" . }}-endpoint-reader labels: app: {{ template "rabbitmq.name" . }} chart: {{ template "rabbitmq.chart" . }} release: "{{ .Release.Name }}" heritage: "{{ .Release.Service }}" subjects: - kind: ServiceAccount name: {{ template "rabbitmq.fullname" . }} roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: {{ template "rabbitmq.fullname" . }}-endpoint-reader {{- end }}
Diagram menunjukkan bahwa kami mengizinkan proses yang berjalan di pod RabbitMQ untuk melakukan operasi
get pada objek
Endpoint . Ini adalah serangkaian operasi minimum yang diperlukan agar semuanya berfungsi. Pada saat yang sama, kami tahu bahwa bagan yang digunakan aman dan tidak akan melakukan tindakan yang tidak diinginkan di dalam kluster Kubernetes.
Pikiran terakhir
Untuk bekerja dengan Kubernetes dalam produksi, kebijakan RBAC bukan opsional. Mereka tidak dapat dianggap sebagai satu set objek API yang hanya diketahui oleh administrator. Pengembang sebenarnya membutuhkan mereka untuk menggunakan aplikasi yang aman dan memanfaatkan sepenuhnya potensi yang ditawarkan oleh Kubernetes API untuk aplikasi cloud-asli. Informasi lebih lanjut tentang RBAC dapat ditemukan di tautan ini:
PS dari penerjemah
Baca juga di blog kami: