Geekly articles weekly

Pengguna dan Otorisasi Kubernetes RBAC

Catatan perev. : Melanjutkan topik keamanan Kubernetes yang baru diangkat secara umum dan RBAC pada khususnya, kami menerbitkan terjemahan materi ini dari konsultan Perancis dari perusahaan internasional Adaltas Big Data. Penulis menunjukkan secara rinci cara membuat pengguna, memberi mereka hak dan terus melayani.

Menyiapkan dan memulai kluster Kubernetes hanyalah permulaan: itu perlu dieksploitasi juga. Untuk mengamankan akses ke cluster, Anda perlu mengatur kredensial pengguna dan mengelola pengaturan otentikasi dan otorisasi dengan benar.

(Ilustrasi diambil dari blog CNCF - sekitar. Terjemahan.)

Artikel ini adalah tentang cara membuat pengguna menggunakan sertifikat klien X.509 , dan cara mengelola otorisasi menggunakan API RBAC dasar di Kubernetes. Kami juga akan berbicara tentang beberapa proyek open source yang menyederhanakan administrasi cluster: rakkess, kubectl-who-can, rbac-lookup, dan RBAC Manager.

Prasyarat dan Asumsi


Pertama-tama, perlu membuat beberapa asumsi:


Jika Anda tidak memiliki cluster Kubernetes yang sudah jadi, saya sarankan Anda merujuk ke artikel rekan (Arthur BUSSER) di mana ia berbicara tentang menginstal Kubernetes di CentOS 7 menggunakan Vagrant.

Ada 4 node di cluster kami: satu master dan 3 pekerja. Wizard juga akan digunakan sebagai simpul tepi untuk berinteraksi dengan cluster.

API RBAC


Kontrol akses berbasis peran (RBAC) adalah metode untuk mengontrol akses ke komputer dan sumber daya jaringan, berdasarkan pada peran masing-masing pengguna dalam suatu perusahaan. RBAC dapat digunakan dengan semua sumber daya Kubernetes yang mendukung CRUD (Buat, Baca, Perbarui, Hapus). Contoh sumber daya tersebut:

  • ruang nama
  • Polong
  • Penugasan
  • volume persisten (Volume Persisten);
  • ConfigMaps

Dan berikut ini adalah contoh operasi yang mungkin dilakukan dengan mereka:

  • create ;
  • get
  • delete (delete) ;
  • list (tampilan list ) ;
  • update .

Untuk mengelola RBAC di Kubernetes, kita perlu mendeklarasikan:

  • Role dan Role ClusterRole . Ini hanyalah set aturan yang mewakili seperangkat izin. Role hanya dapat digunakan untuk menyediakan akses ke sumber daya dalam ruang nama. ClusterRole dapat memberikan izin yang sama dengan Role , dan juga memberikan akses ke sumber daya yang tersedia di seluruh cluster, dan yang disebut titik akhir non-sumber daya (seperti /healthz - approx. Terjemahan.) .
  • Subjects Subjek adalah entitas yang akan melakukan operasi dalam sebuah cluster. Itu bisa pengguna, layanan, atau bahkan grup.
  • RoleBinding dan ClusterRoleBinding . Seperti namanya, ini hanyalah pengikatan subjek ke Peran atau ClusterRole.

Kubernetes memiliki peran default berikut:

  • view : akses hanya baca, tidak termasuk rahasia;
  • edit : di atas + kemampuan untuk mengedit sebagian besar sumber daya, tidak termasuk peran dan ikatan peran;
  • admin : di atas + kemampuan untuk mengelola peran dan pemetaan peran di tingkat namespace;
  • cluster-admin : semua hak istimewa yang mungkin.

Tentu saja, Anda dapat membuat Roles dan ClusterRoles Anda sendiri, tetapi kami menyarankan Anda menggunakan peran default sebanyak mungkin, jika situasinya memungkinkan. Jika tidak, Anda dapat dengan cepat menjadi bingung dalam semua ini.

Contoh penggunaan


Kami akan membuat dua ruang nama: my-project-dev dan my-project-prod , - serta dua pengguna: jean dan sarah - dengan peran berbeda di ruang nama ini:

  • my-project-dev:
    • jean: edit
  • my-project-prod:
    • jean: view
    • sarah: sunting

Buat dan otentikasi pengguna menggunakan sertifikat klien X.509


Biasanya, ada dua jenis pengguna: akun layanan yang dikelola oleh Kubernetes, dan pengguna reguler. Kami akan fokus pada yang terakhir. Begini cara mereka dijelaskan dalam dokumentasi resmi:

Diasumsikan bahwa pengguna reguler dikelola oleh layanan eksternal dan independen. Peran tersebut dapat dimainkan oleh administrator yang membagikan kunci pribadi, repositori pengguna seperti Keystone atau Akun Google, atau bahkan file dengan daftar nama pengguna dan kata sandi. Dalam hal ini, Kubernetes tidak memiliki objek yang mewakili pengguna biasa. Pengguna biasa tidak dapat ditambahkan ke cluster melalui panggilan API.

Ada beberapa cara untuk mengelola pengguna biasa:

  • Auth dasar:
    • mentransfer konfigurasi ke server API dengan konten (atau serupa) berikut ini: kata sandi, nama pengguna, uid, grup;
  • Sertifikat Klien X.509:
    • pembuatan kunci rahasia pengguna dan permintaan penandatanganan sertifikat;
    • sertifikasi dalam otoritas sertifikasi (Kubernetes CA) untuk mendapatkan sertifikat pengguna;
  • Token Pembawa (Token Web JSON, JWT):
    • OpenID Connect
    • lapisan otentikasi di atas OAuth 2.0;
    • webhooks

Pada artikel ini, kita akan menggunakan sertifikat X.509 dan OpenSSL karena kesederhanaannya. Menciptakan pengguna terjadi dalam beberapa tahap - kami akan membahas semuanya. Operasi harus dilakukan di bawah akun pengguna dengan hak administrator cluster (cluster-admin). Berikut ini semua langkah untuk membuat pengguna (menggunakan jean sebagai contoh):

  • Buat pengguna di wizard, dan kemudian pergi ke direktori rumahnya untuk menyelesaikan langkah-langkah yang tersisa:

     useradd jean && cd /home/jean
  • Buat kunci pribadi:

     openssl genrsa -out jean.key 2048
  • Buat permintaan penandatanganan sertifikat (CSR). CN adalah nama pengguna, O adalah grup. Anda dapat mengatur izin berdasarkan grup. Ini akan menyederhanakan pekerjaan jika, misalnya, Anda memiliki banyak pengguna dengan izin yang sama:

     #   openssl req -new -key jean.key \ -out jean.csr \ -subj "/CN=jean" #     $group openssl req -new -key jean.key \ -out jean.csr \ -subj "/CN=jean/O=$group" #       openssl req -new -key jean.key \ -out jean.csr \ -subj "/CN=jean/O=$group1/O=$group2/O=$group3"
  • Masuk CSR di Kubernetes CA. Kita harus menggunakan sertifikat dan kunci CA, yang biasanya ditemukan di /etc/kubernetes/pki . Sertifikat akan berlaku selama 500 hari:

     openssl x509 -req -in jean.csr \ -CA /etc/kubernetes/pki/ca.crt \ -CAkey /etc/kubernetes/pki/ca.key \ -CAcreateserial \ -out jean.crt -days 500
  • Buat direktori .certs . Di dalamnya kami akan menyimpan kunci publik dan pribadi pengguna:

     mkdir .certs && mv jean.crt jean.key .certs
  • Buat pengguna di dalam Kubernetes:

     kubectl config set-credentials jean \ --client-certificate=/home/jean/.certs/jean.crt \ --client-key=/home/jean/.certs/jean.key
  • Tetapkan konteks untuk pengguna:

     kubectl config set-context jean-context \ --cluster=kubernetes --user=jean
  • Edit file konfigurasi pengguna. Ini berisi informasi yang diperlukan untuk otentikasi dalam sebuah cluster. Anda dapat menggunakan file konfigurasi cluster, yang biasanya terletak di /etc/kubernetes : /etc/kubernetes certificate-authority-data dan server harus sama seperti pada file yang disebutkan:

     apiVersion: v1 clusters: - cluster: certificate-authority-data: {  } server: {  } name: kubernetes contexts: - context: cluster: kubernetes user: jean name: jean-context current-context: jean-context kind: Config preferences: {} users: - name: jean user: client-certificate: /home/jean/.certs/jean.cert client-key: /home/jean/.certs/jean.key

    Sekarang Anda perlu menyalin konfigurasi di atas ke direktori .kube :

     mkdir .kube && vi .kube/config
  • Tetap menjadikan pengguna pemilik semua file dan direktori yang dibuat:

     chown -R jean: /home/jean/

Pengguna jean berhasil dibuat. Kami akan melakukan hal yang sama untuk sarah . Ada beberapa langkah, dan menciptakan banyak pengguna bisa memakan waktu lama. Oleh karena itu, saya menulis skrip Bash yang mengotomatiskan proses: mereka dapat ditemukan di repositori di GitHub .

Catatan perev. : Seperti yang kami tulis dalam artikel terbaru kami , prosedur ini dapat disederhanakan dengan cara yang lebih "asli" ke Kubernetes - melalui fitur baru di utilitas konsol kubeadm . Namun, ingatlah bahwa pada saat publikasi terjemahan ini, mereka tersedia dalam bentuk alfa. Contoh dari perintah untuk membuat pengguna adalah kubeadm alpha kubeconfig user .

Kami sekarang memiliki pengguna, dan kami dapat terus membuat dua ruang nama:

 kubectl create namespace my-project-dev kubectl create namespace my-project-prod

Karena kami belum menentukan otorisasi pengguna, mereka seharusnya tidak memiliki akses ke sumber daya cluster:

 User: Jean kubectl get nodes Error from server (Forbidden): nodes is forbidden: User "jean" cannot list resource "nodes" in API group "" at the cluster scope kubectl get pods -n default Error from server (Forbidden): pods is forbidden: User "jean" cannot list resource "pods" in API group "" in the namespace "default" kubectl get pods -n my-project-prod Error from server (Forbidden): pods is forbidden: User "jean" cannot list resource "pods" in API group "" in the namespace "my-project-prod" kubectl get pods -n my-project-dev Error from server (Forbidden): pods is forbidden: User "jean" cannot list resource "pods" in API group "" in the namespace "my-project-dev" 

 User: Sarah kubectl get nodes Error from server (Forbidden): nodes is forbidden: User "sarah" cannot list resource "nodes" in API group "" at the cluster scope kubectl get pods -n default Error from server (Forbidden): pods is forbidden: User "sarah" cannot list resource "pods" in API group "" in the namespace "default" kubectl get pods -n my-project-prod Error from server (Forbidden): pods is forbidden: User "sarah" cannot list resource "pods" in API group "" in the namespace "my-project-prod" kubectl get pods -n my-project-dev Error from server (Forbidden): pods is forbidden: User "sarah" cannot list resource "pods" in API group "" in the namespace "my-project-dev"

Pembuatan Peran dan Peran Cluster


Kami akan menggunakan ClusterRole , tersedia secara default. Namun, kami juga menunjukkan cara membuat Role dan ClusterRole Anda sendiri. Intinya, Role dan ClusterRole hanyalah serangkaian tindakan (disebut verbs , yaitu, kata demi kata) yang diizinkan untuk sumber daya dan ruang nama tertentu. Ini adalah contoh file YAML:

 apiVersion: rbac.authorization.k8s.io/v1beta1 kind: Role metadata: name: list-deployments namespace: my-project-dev rules: - apiGroups: [ apps ] resources: [ deployments ] verbs: [ get, list ] --------------------------------- apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRole metadata: name: list-deployments rules: - apiGroups: [ apps ] resources: [ deployments ] verbs: [ get, list ]

Untuk membuatnya, jalankan perintah:

 kubectl create -f /path/to/your/yaml/file

Mengikat Peran atau Peran Cluster untuk Pengguna


Sekarang ikat ClusterRole default ( edit dan view ) kepada pengguna kami sebagai berikut:

  • jean :
    • edit - di namespace my-project-dev ;
    • view - di namespace my-project-prod ;
  • sarah :
    • edit - di namespace my-project-prod .

RoleBindings harus ditentukan oleh ruang nama, bukan oleh pengguna. Dengan kata lain, untuk mengesahkan jean kita akan membuat dua RoleBindings. Contoh file YAML yang mendefinisikan RoleBindings untuk jean :

 apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: jean namespace: my-project-dev subjects: - kind: User name: jean apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: edit apiGroup: rbac.authorization.k8s.io --------------------------------- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: jean namespace: my-project-prod subjects: - kind: User name: jean apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: view apiGroup: rbac.authorization.k8s.io

Kami mengizinkan jean view my-project-prod dan mengedit my-project-dev . Hal yang sama perlu dilakukan dengan otorisasi untuk sarah . Untuk mengaktifkannya, jalankan perintah:

 kubectl apply -f /path/to/your/yaml/file

Dalam hal ini, kubectl apply digunakan sebagai pengganti kubectl create . Perbedaan antara keduanya adalah bahwa create menciptakan objek dan tidak melakukan apa-apa lagi, dan apply - tidak hanya menciptakan objek (jika tidak ada), tetapi juga memperbarui jika perlu.

Mari kita periksa apakah pengguna kami telah menerima izin yang diperlukan.

  • Pengguna: sarah ( edit di my-project-prod )
    • my-project-prod
      • can daftar pods (1);
      • dapat membuat penyebaran (2).
    • my-project-dev
      • tidak dapat mencantumkan pod (4);
      • tidak dapat membuat penyebaran (5).

 (1) kubectl get pods -n my-project-prod No resources found. (2) kubectl run nginx --image=nginx --replicas=1 -n my-project-prod deployment.apps/nginx created (3) kubectl get pods -n my-project-prod NAME READY STATUS RESTARTS AGE nginx-7db9fccd9b-t14qw 1/1 Running 0 4s (4) kubectl get pods -n my-project-dev Error from server (Forbidden): pods is forbidden: User "sarah" cannot list resource "pods" in API group "" in the namespace "my-project-dev" (5) kubectl run nginx --image=nginx --replicas=1 -n my-project-dev Error from server (Forbidden): deployments.apps is forbidden: User "sarah" cannot create resource "deployments" in API group "apps" in the namespace "my-project-dev"

  • Pengguna: jean ( view di my-project-prod dan edit di my-project-dev )
    • my-project-prod
      • can daftar pods (1);
      • dapat mendaftar deployment'ov (2);
      • tidak dapat menghapus penyebaran (3).
    • my-project-dev:
      • can daftar pods (4);
      • dapat membuat penyebaran (5);
      • dapat mendaftar deployment'ov (6);
      • dapat menghapus penyebaran (7).

 (1) kubectl get pods -n my-project-prod NAME READY STATUS RESTARTS AGE nginx-7db9fccd9b-t14qw 1/1 Running 0 101s (2) kubectl get deploy -n my-project-prod NAME READY UP-TO-DATE AVAILABLE AGE nginx 1/1 1 1 110s (3) kubectl delete deploy/nginx -n my-project-prod Error from server (Forbidden): deployments.extensions "nginx" is forbidden: User "jean" cannot delete resource "deployments" in API group "extensions" in the namespace "my-project-prod" (4) kubectl get pods -n my-project-dev No resources found. (5) kubectl run nginx --image=nginx --replicas=1 -n my-project-dev deployment.apps/nginx created (6) kubectl get deploy -n my-project-dev NAME READY UP-TO-DATE AVAILABLE AGE nginx 0/1 1 0 13s (7) kubectl delete deploy/nginx -n my-project-dev deployment.extensions "nginx" deleted (8) kubectl get deploy -n my-project-dev No resources found.

Manajemen dan otorisasi pengguna


Jadi, kami telah berhasil menetapkan berbagai peran dan otorisasi pengguna. Muncul pertanyaan: bagaimana sekarang mengelola semua ini? Bagaimana saya tahu jika izin untuk pengguna tertentu diatur dengan benar? Bagaimana saya tahu siapa yang memiliki wewenang untuk melakukan tindakan tertentu? Bagaimana cara mendapatkan gambaran umum tentang izin pengguna?

Kami membutuhkan jawaban untuk semua pertanyaan ini untuk memastikan keamanan cluster. Perintah kubectl auth can-i memungkinkan Anda untuk mengetahui apakah pengguna dapat melakukan tindakan tertentu:

 # kubectl auth can-i $action $resource --as $subject (1) kubectl auth can-i list pods (2) kubectl auth can-i list pods --as jean

Perintah pertama (1) memungkinkan pengguna untuk mengetahui apakah ia dapat melakukan beberapa tindakan. Yang kedua (2) - memungkinkan administrator untuk menyamar sebagai pengguna untuk mencari tahu apakah dia dapat melakukan tindakan tertentu. "Reinkarnasi" ini hanya diizinkan untuk pengguna dengan hak administrator cluster.

Ini praktis semua yang bisa dilakukan dengan toolkit bawaan. Itulah sebabnya saya akan mempresentasikan beberapa proyek Open Source yang memperluas kemampuan yang ditawarkan oleh tim can-i kubectl auth. Sebelum memperkenalkan mereka, mari kita tentukan dependensi: Pergi dan Krew .

Pergi instalasi


Go adalah bahasa pemrograman open source yang memungkinkan Anda membuat perangkat lunak yang sederhana, andal, dan efisien. Ini dikembangkan oleh Google di bawah inspirasi C dan Pascal, berdasarkan pada konsep asli Robert Griesemer , Rob Pike dan Ken Thompson .

 wget https://dl.google.com/go/go1.12.5.linux-amd64.tar.gz sudo tar -C /usr/local -xzf go1.12.5.linux-amd64.tar.gz export PATH=$PATH:/usr/local/go/bin

Instalasi Krew


Krew adalah alat yang menyederhanakan penggunaan plugin kubectl . Krew membantu Anda menemukan, menginstal, dan mengelola plugin. Dari segi fungsi, itu menyerupai alat seperti apt, dnf atau minuman. Krew hanya kompatibel dengan kubectl versi 1.12 dan lebih tinggi.

 set -x; cd "$(mktemp -d)" && curl -fsSLO "https://storage.googleapis.com/krew/v0.2.1/krew.{tar.gz,yaml}" && tar zxvf krew.tar.gz && ./krew-"$(uname | tr '[:upper:]' '[:lower:]')_amd64" install \ --manifest=krew.yaml --archive=krew.tar.gz export PATH="${KREW_ROOT:-$HOME/.krew}/bin:$PATH"

rakkess


Proyek ini memungkinkan Anda untuk melihat semua izin yang telah diberikan kepada pengguna. Misalnya, ini membantu menjawab pertanyaan tentang apa yang dapat dilakukan jean . Pertama-tama, mari kita instal:

 kubectl krew install access-matrix

Dokumentasi proyek dapat ditemukan di repositori di GitHub . Berikut ini contoh karyanya:

 kubectl access-matrix -n my-project-dev --as jean



kubect-who-can


Proyek ini memungkinkan kami untuk mencari tahu pengguna mana yang dapat melakukan tindakan tertentu. Akan membantu menjawab pertanyaan: "Siapa yang bisa melakukan ini?" Instalasi:

 go get -v github.com/aquasecurity/kubectl-who-can

Dokumentasinya ada di repositori GitHub . Contoh kerja:

 kubectl-who-can list pods -n default No subjects found with permissions to list pods assigned through RoleBindings CLUSTERROLEBINDING SUBJECT TYPE SA-NAMESPACE cluster-admin system:masters Group rbac-manager rbac-manager ServiceAccount rbac-manager system:controller:attachdetach-controller attachdetach-controller ServiceAccount kube-system system:controller:clusterrole-aggregation-controller clusterrole-aggregation-controller ServiceAccount kube-system system:controller:cronjob-controller cronjob-controller ServiceAccount kube-system system:controller:daemon-set-controller daemon-set-controller ServiceAccount kube-system system:controller:deployment-controller deployment-controller ServiceAccount kube-system system:controller:endpoint-controller endpoint-controller ServiceAccount kube-system system:controller:generic-garbage-collector generic-garbage-collector ServiceAccount kube-system system:controller:horizontal-pod-autoscaler horizontal-pod-autoscaler ServiceAccount kube-system system:controller:job-controller job-controller ServiceAccount kube-system system:controller:namespace-controller namespace-controller ServiceAccount kube-system system:controller:node-controller node-controller ServiceAccount kube-system system:controller:persistent-volume-binder persistent-volume-binder ServiceAccount kube-system system:controller:pod-garbage-collector pod-garbage-collector ServiceAccount kube-system system:controller:pvc-protection-controller pvc-protection-controller ServiceAccount kube-system system:controller:replicaset-controller replicaset-controller ServiceAccount kube-system system:controller:replication-controller replication-controller ServiceAccount kube-system system:controller:resourcequota-controller resourcequota-controller ServiceAccount kube-system system:controller:statefulset-controller statefulset-controller ServiceAccount kube-system system:coredns coredns ServiceAccount kube-system system:kube-controller-manager system:kube-controller-manager User system:kube-scheduler system:kube-scheduler User

rbac-lookup


Proyek ini memberikan gambaran umum tentang aturan RBAC. Ini membantu menjawab pertanyaan: "Peran apa yang dimiliki jean dan sarah ?", "Peran apa yang dimiliki semua pengguna?", "Peran apa yang dimiliki seluruh kelompok?". Untuk menginstal, jalankan perintah:

 kubectl krew install rbac-lookup

Dokumentasinya ada di repositori GitHub . Ini adalah contoh pekerjaan:

 kubectl-rbac_lookup jean SUBJECT SCOPE ROLE jean my-project-dev ClusterRole/edit jean my-project-prod ClusterRole/view kubectl-rbac_lookup sarah SUBJECT SCOPE ROLE sarah my-project-prod ClusterRole/edit kubectl-rbac_lookup --kind user SUBJECT SCOPE ROLE jean my-project-dev ClusterRole/edit jean my-project-prod ClusterRole/view sarah my-project-prod ClusterRole/edit system:anonymous kube-public Role/kubeadm:bootstrap-signer-clusterinfo system:kube-controller-manager kube-system Role/extension-apiserver-authentication-reader system:kube-controller-manager kube-system Role/system::leader-locking-kube-controller-manager system:kube-controller-manager cluster-wide ClusterRole/system:kube-controller-manager system:kube-proxy cluster-wide ClusterRole/system:node-proxier system:kube-scheduler kube-system Role/extension-apiserver-authentication-reader system:kube-scheduler kube-system Role/system::leader-locking-kube-scheduler system:kube-scheduler cluster-wide ClusterRole/system:kube-scheduler system:kube-scheduler cluster-wide ClusterRole/system:volume-scheduler kubectl-rbac_lookup --kind group SUBJECT SCOPE ROLE system:authenticated cluster-wide ClusterRole/system:basic-user system:authenticated cluster-wide ClusterRole/system:discovery system:authenticated cluster-wide ClusterRole/system:public-info-viewer system:bootstrappers:kubeadm:default-node-token cluster-wide ClusterRole/system:node-bootstrapper system:bootstrappers:kubeadm:default-node-token cluster-wide ClusterRole/system:certificates.k8s.io:certificatesigningrequests:nodeclient system:bootstrappers:kubeadm:default-node-token kube-system Role/kube-proxy system:bootstrappers:kubeadm:default-node-token kube-system Role/kubeadm:kubelet-config-1.14 system:bootstrappers:kubeadm:default-node-token kube-system Role/kubeadm:nodes-kubeadm-config system:masters cluster-wide ClusterRole/cluster-admin system:nodes kube-system Role/kubeadm:kubelet-config-1.14 system:nodes kube-system Role/kubeadm:nodes-kubeadm-config system:nodes cluster-wide ClusterRole/system:certificates.k8s.io:certificatesigningrequests:selfnodeclient system:unauthenticated cluster-wide ClusterRole/system:public-info-viewer

Manajer RBAC


Seperti yang tersirat dari nama proyek ini , ia adalah manajer RBAC. Ini menyederhanakan banyak manipulasi yang diperlukan. Mungkin yang paling penting adalah pembuatan RoleBindings. Kami melihat sebelumnya bahwa ketika membuat peran yang berbeda untuk pengguna, perlu untuk membuat RoleBindings yang berbeda. RBAC Manager membantu dengan memungkinkan Anda membuat hanya satu RoleBinding dengan semua otorisasi sekaligus. Untuk menginstal, Anda harus mengunduh file YAML dari repositori di GitHub:

 kubectl apply -f /path/to/rbac/manager/yaml/file

Dokumentasi resmi ada di repositori GitHub . Contoh kerja:

 apiVersion: rbacmanager.reactiveops.io/v1beta1 kind: RBACDefinition metadata: name: jose rbacBindings: - name: jose subjects: - kind: User name: jose roleBindings: - namespace: my-project-prod clusterRole: edit - namespace: my-project-dev clusterRole: edit

Kesimpulan


Kami menciptakan pengguna di kluster Kubernetes menggunakan sertifikat klien X.509 dengan OpenSSL dan memberdayakan mereka. Untuk pembuatan yang lebih mudah, Anda dapat menggunakan skrip yang tersedia di repositori saya di GitHub (atau perintah kubeadm eksperimental - sekitar Terjemahan.) . Adapun administrasi klaster, Anda dapat menggunakan proyek Open Source yang disajikan dalam artikel:

  • kubectl auth can-i : cari tahu apakah pengguna dapat melakukan beberapa tindakan;
  • rakkess : cari tahu semua tindakan yang dapat dilakukan pengguna;
  • kubectl-who-can : menentukan pengguna mana yang dapat melakukan beberapa tindakan;
  • rbac-lookup : dapatkan gambaran umum tentang RBAC;
  • Manajer RBAC : Sederhanakan konfigurasi dengan menggabungkan binding hak, mengotomatisasi perubahan ke RBAC, menggunakan label sebagai penyeleksi untuk menetapkan hak.

Membuat pengguna dapat berubah menjadi tugas yang sangat memakan waktu, terutama jika Anda perlu mengatur sejumlah besar pengguna sekaligus (atau sering membuatnya). Untuk meringankan situasi ini dapat menghubungkan LDAP perusahaan ke kluster Kubernetes. Beberapa proyek Sumber Terbuka ( Kismatik [ Objek tampak seperti ditinggalkan - kira-kira Terjemahkan.] Dan ObjectifLibre ) menawarkan webhook Kubernetes yang memungkinkan otentikasi langsung melalui LDAP. Solusi lain yang mungkin adalah mengkonfigurasi server OpenID dengan LDAP perusahaan sebagai backend.

PS dari penerjemah


Baca juga di blog kami:

Source: https://habr.com/ru/post/id470503/

More articles:


All Articles