Kubernetes 101: Service Account

Service account di Kubernetes itu dipake buat ngasih identitas ke proses yang jalan di Pod. Kalo user account buat manusia, service account ini buat proses-proses di dalam Pod kamu.

Perkenalan

Service account di Kubernetes itu buat ngasih identitas ke proses yang jalan di Pod. Kalo user account buat manusia, service account ini buat proses-proses di dalam Pod kamu.

Singkatnya, service account ngautentikasi aplikasi atau layanan yang jalan di Pod, bukan user. Mereka otomatis ditugaskan sama secret, yang isinya kredensial buat autentikasi ke Kubernetes API. Secret ini otomatis dibuat dan dikaitin ke service account pas service account-nya dibuat.

Peran Service Account

Service account punya peran penting di skenario Kubernetes nyata. Misalnya, kalo sebuah Pod perlu interaksi sama Kubernetes API buat ambil detail tentang resource lain di namespace atau cluster yang sama, Pod butuh identitas—di sinilah service account masuk.

Contohnya, bayangin kamu punya Deployment yang jalanin banyak Pod yang interaksi sama Kubernetes API. Daripada kasih izin ke tiap Pod, kamu bisa bikin service account dengan izin yang dibutuhin dan hubungin ke Deployment. Jadi, semua Pod di bawah Deployment itu bakal mewarisi service account ini dan punya izin buat interaksi sama Kubernetes API.

Jadi, service account di Kubernetes ngasih identitas ke proses yang jalan di pod. Peran utamanya buat autentikasi dan otorisasi proses yang jalan di pod buat interaksi sama Kubernetes API, dan ini jadi bagian integral dari sistem RBAC (Role-Based Access Control) di Kubernetes.

Ini beberapa peran utama service account di Kubernetes:

1. Autentikasi Proses di Pods: Service account dipake buat autentikasi proses yang jalan di pods ke server Kubernetes API. Pas service account dibuat, Kubernetes otomatis bikin secret yang isinya token buat autentikasi request ke server Kubernetes API. Token ini otomatis dimount ke pods yang dikaitin sama service account tersebut.
2. Otorisasi Akses ke Resources: Service account juga dipake buat otorisasi tindakan di resources Kubernetes. Dengan RoleBinding atau ClusterRoleBinding, kamu bisa ngaitin service account ke Role atau ClusterRole yang nentuin izin-izin tertentu. Service account ini bisa dipake proses yang jalan di pods buat ngelakuin tindakan yang diotorisasi di server Kubernetes API.
3. Isolasi Antar Namespace: Service account ada di namespace, jadi dia punya scope buat izin dan cara buat misahin akses ke resources di namespace yang beda. Service account di satu namespace nggak bisa akses resources di namespace lain kecuali ada ClusterRoles dan ClusterRoleBindings yang tepat.
4. Otomatisasi Proses di Pods: Banyak proses otomatis di Kubernetes, kayak ngakses Kubernetes API dari dalam pod, baca ConfigMaps, atau ngontrol pod lain, yang pake service account. Proses sistem Kubernetes kayak kube-controller-manager dan kube-scheduler juga jalan di bawah service account.
5. Integrasi pake Cloud IAMs: Beberapa penyedia cloud ngasih kemampuan buat ngaitin service account Kubernetes sama peran IAM (Identity and Access Management) cloud. Ini ngizinin pods Kubernetes buat pake peran IAM yang terkait buat autentikasi dan interaksi sama layanan cloud.

Service Account dan RBAC

RBAC, alias Role-Based Access Control, itu cara buat ngatur akses ke komputer atau jaringan berdasarkan peran pengguna di organisasi kamu. Di Kubernetes, RBAC dipake buat ngontrol siapa (user atau service account) yang bisa ngelakuin tindakan (kayak: get, list, create, update, delete) di resource tertentu (kayak: pods, services, nodes).

RBAC pake API group rbac.authorization.k8s.io buat ngambil keputusan otorisasi, jadi admin bisa ngatur kebijakan lewat Kubernetes API secara dinamis.

Ini dia hubungan Service Account dan RBAC:

Roles dan ClusterRoles

Ini kumpulan izin yang mewakili grup logis operasi API di sekumpulan resource. Role itu izin di dalam namespace tertentu, sementara ClusterRole itu versi yang mencakup seluruh cluster dan bisa ngasih akses ke resource skala cluster (kayak nodes) dan endpoint non-resource (kayak /healthz).

RoleBindings dan ClusterRoleBindings

RoleBindings dan ClusterRoleBindings dipake buat ngasih izin yang didefinisiin di Role ke user atau sekumpulan user. Mereka bisa juga dipake buat ngasih izin ke service accounts. RoleBinding ngasih izin di Role ke user atau sekumpulan user dalam namespace tertentu. ClusterRoleBinding itu versi skala cluster dari RoleBinding, ngasih izin global di semua namespace.

Saat kamu bikin service account, default-nya nggak ngasih izin apapun. Jadi kamu harus eksplisit bind service account ke Role atau ClusterRole pake RoleBinding atau ClusterRoleBinding.

Misalnya, kalo kamu punya service account namanya my-service-account di namespace my-namespace, dan kamu mau ngasih izin buat get, watch, dan list pods di namespace yang sama, kamu bakal bikin Role dengan izin-izin tersebut dan kemudian bikin RoleBinding yang ngasih Role ini ke my-service-account.

Sistem ini bikin kontrol akses jadi lebih rinci, jadi service accounts cuma punya izin yang pas buat tugas mereka, gak lebih. Ini sesuai dengan prinsip least privilege, alias ngasih akses seminimal mungkin yang dibutuhin. Prinsip ini penting banget buat keamanan.

Dengan RBAC dan service accounts, kamu bisa batasi potensi kerusakan kalo sampe kredensial service account bocor. Jadi, walaupun ada yang berhasil dapet akses service account, mereka gak bisa ngelakuin lebih dari yang seharusnya. Jadi lebih aman, kan?

Contoh Service Account Manifest

Ini dia contoh manifest yang mencakup ServiceAccount, Role, dan RoleBinding di Kubernetes. ONXP bakal bikin ServiceAccount namanya example-serviceaccount, Role yang bisa baca Pods di namespace default, sama RoleBinding buat ngaitin keduanya.

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: example-serviceaccount
  namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: ServiceAccount
  name: example-serviceaccount
  namespace: default
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.i

Detail manifest:

• ServiceAccount: Ini ngedefinisiin service account baru yang dinamain example-serviceaccount di namespace default. kind: ServiceAccount and apiVersion: v1 nunjukkin kalo kamu udah buat objek service account.
• Role: Terus, kita bahas Role yang dinamain pod-reader di namespace default. Peran ini punya izin buat “get”, “watch, dan “list” Pod (resources: ["pods"]) di dalam namespace default. Ini bagian apiGroups: [""] nyambung ke apiGroup yang berhubungan sama resource Pods, yang masuk ke dalam core API group.
• RoleBinding: Terakhir, kita bikin RoleBinding yang namanya read-pods yang nge-assign example-serviceaccount kita ke Role pod-reader yang tadi kita buat. Yang roleRef merujuk ke Role yang kita mau bind, dan yang subjects daftarin user, grup, atau service account yang kena apply RoleBinding-nya. Di kasus kita, subject-nya itu example-serviceaccount.

Kalo kamu jalanin kubectl apply -f filename.yaml pake manifest ini, example-serviceaccount bakal bisa baca Pods (kayak get, watch, dan list) di default namespace.

Contoh ini nunjukin gimana RBAC dan ServiceAccounts kerjasama di Kubernetes. Dengan RoleBinding, kamu ngasih ServiceAccount izin-izin spesifik yang didefinisiin sama Role, jadi dia bisa berinteraksi sama server API Kubernetes.