Giriş
Service account bir token sağlar. Bu token Kubernetes tarafından doğrulama için kullanılır. Şeklen şöyle
Account Tipleri
Açıklaması şöyle.
What Is Service Account in Kubernetes?There are two types of account in Kubernetes1. User Account: It is used to allow us, humans, to access the given Kubernetes cluster. Any user needs to get authenticated by the API server to do so. A user account can be an admin or a developer who is trying to access the cluster level resources.2. Service Account: It is used to authenticate machine level processes to get access to our Kubernetes cluster. The API server is responsible for such authentication to the processes running in the pod
Açıklaması şöyle
So, a service account is an identity that is attached to the processes running within a pod.
Service Account yaratmak için
1. kind: ServiceAccount yaml kullanılabilir.
2. kubectl create sa kullanılabilir
Service Account İçinde Permission'lar Vardır
- Bu persmission'lar hangi resource'lara create veya get yapılabileceğini gösterir. - Permission'lar ClusterRole ve Role ile değiştirilebilir.
- Default Service Account içinde az sayıda ve çoğunlukla salt okunur permission'lar vardır.
Örnek - Role Değiştirme
Şöyle yaparız. Böylece Role ile pods kaynağına get, watch, list hakkı verilir. kubectl get pods hata dönmez.
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: dev name: pod-reader rules: - apiGroups: [""] # "" indicates the core API group resources: ["pods"] verbs: ["get", "watch", "list"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: read-pods subjects: - kind: ServiceAccount name: pod-access namespace: dev roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io
Örnek - ClusterRole Değiştirme
Şöyle yaparız. cronjobs kaynaklarıyla ilgili her şeye erişim verir.
kind: ClusterRoleapiVersion: rbac.authorization.k8s.io/v1metadata:name: job-masterrules:- apiGroups:- batchresources:- cronjobsverbs:- create- delete- deletecollection- get- list- patch- update- watch
Açıklaması şöyle
We will now create two RoleBinding objects (not ClusterRoleBinding) which will use the ClusterRole job-master from above to allow the ServiceAccount sa to perform various actions (verbs) on cronjobs in two namespaces:
Daha sonra şöyle yaparız. roleRef alanında ClusterRole nesnesine atıfta bulunuluyor. subjects alanında kime erişim verildiği belirtiliyor
apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: job-master-1 namespace: namespace1 roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: job-master subjects: - kind: ServiceAccount name: sa namespace: default --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: job-master-2 namespace: namespace2 roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: job-master subjects: - kind: ServiceAccount name: sa namespace: default
Denemek için şöyle yaparız
#yes. namespace1 and cronjobs kubectl auth can-i get cronjobs -n namespace1 --as system:serviceaccount:default:sa #yes. namespace1 and cronjobs kubectl auth can-i delete cronjobs -n namespace2 --as system:serviceaccount:default:sa #no because of namespace3 kubectl auth can-i get cronjobs -n namespace3 --as system:serviceaccount:default:sa #no #no because of pod kubectl auth can-i get pod -n namespace2 --as system:serviceaccount:default:sa
Örnek - ClusterRole Değiştirme
Şöyle yaparız.
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: pv-sc-access rules: - apiGroups: [""] resources: ["persistentvolumes"] verbs: ["get", "watch", "list"] - apiGroups: ["storage.k8s.io"] resources: ["storageclasses"] verbs: ["get", "watch", "list"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: pv-sc-binding namespace: dev subjects: - kind: ServiceAccount name: pod-access namespace: dev #namespace of the service account roleRef: kind: ClusterRole name: pv-sc-access apiGroup: rbac.authorization.k8s.io
Örnek - Default Service Account
Elimizde bir default service account kullanan pod olsun. Bu pod'un permission'larını deneyelim. Şöyle yaparız. Burada 10.25.96.3:6443 kubernetes servisinin sağladığı bir endpoint. Şu anda /api kaynağına erişmeye çalışıyoruz.
# Enter into the pod > kubectl exec -it kubectl-pod bash # Try to access k8s API without SA token > curl -X GET https://10.25.96.3:6443/api --insecure { "kind": "Status", "apiVersion": "v1", "metadata": {}, "status": "Failure", # Access Unsuccessful, Authentication failed. "message": "forbidden: User \"system:anonymous\" cannot get path \"/api\"", "reason": "Forbidden", "details": {}, "code": 403 }
Bu sefer Service Account Token'ı kullanarak şöyle yaparız. Sonuç başarılı
# Try to access k8s API using SA token TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token) > curl -X GET https://10.25.96.3:6443/api/ --header "Authorization: Bearer $TOKEN" \ --insecure { "kind": "APIVersions", "versions": [ "v1" ], "serverAddressByClientCIDRs": [ { "clientCIDR": "0.0.0.0/0", "serverAddress": "10.25.96.3:6443" # Access Successful } ] }
Bu sefer Service Account Token'ı kullanarak şöyle yaparız. Sonuç başarılı
# Try to access k8s API securely using SA token and CA.crt TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token) CA=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt > curl --cacert $CA -X GET https://10.25.96.3:6443/api/ \ --header "Authorization: Bearer $TOKEN"
{ "kind": "APIVersions", "versions": [ "v1" ], "serverAddressByClientCIDRs": [ { "clientCIDR": "0.0.0.0/0", "serverAddress": "10.25.96.3:6443" #Access Successful } ] }
Şimdi permission'ları deneyelim şöyle yaparız. Sonuç başarısız
# Try to list the all the pods within dev namespace TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token) CA=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt > curl --cacert $CA -X GET https://10.25.96.3:6443/api/v1/namespaces/dev/pods/ \ --header "Authorization: Bearer $TOKEN"
{ "kind": "Status", "apiVersion": "v1", "metadata": {}, "status": "Failure", # Access Unsuccessful, lack of permissions "message": "pods is forbidden: User \"system:serviceaccount:dev:pod-access\" cannot list resource \"pods\" in API group \"\" in the namespace \"dev\"", "reason": "Forbidden", "details": { "kind": "pods" }, "code": 403 }
Differences between the User Account and Service Account
Açıklaması şöyle
1. Default Service AccountUser accounts are intended to be global. Names must be unique across all namespaces of a cluster. Service accounts are namespaced.
Açıklaması şöyle
A default service account is automatically created for each namespace. To authenticate with Kubernetes API from pods, the pods must have access to the service account token. Whenever a pod is created without defining service account, it gets attached to the default service account. (a service account token is mounted into the pod in /var/run/secrets/kubernetes.io/serviceaccountdirectory)
Açıklaması şöyle
When you create a pod, if you do not specify a service account, it is automatically assigned the default service account in the same namespace.
Örnek
Şöyle yaparız. Burada dev isimli namespace içinde default service account'un yaratıldığı görülebilir.
# Create namespace> kubectl create namespace dev# Change current context to the new context(namespace)> kubectl config set-context --current --namespace=dev# View the service accounts of dev namespace> kubectl get sa------------------------------------------------------NAME SECRETS AGEdefault 0 5m57s------------------------------------------------------
dev namespace içindeki bir pod'a bakalım. Burada service account'un mount edildiği görülebilir.
# Create a pod > kubectl run kubectl-pod - image=shamimice03/kubectl-image # Inspect the pod # Check if the service account is mounted or not > kubectl describe pod kubectl-pod | grep -A1 Mounts -------------------------------------------------------------------- Mounts: /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-vtm4h (ro) --------------------------------------------------------------------
Service account'un içine bakmak için şöyle yaparız.
# View the permission list of a service account > kubectl auth can-i \ --list \ --as=system:serviceaccount:<service-account-name> \ -n <namespace>
Şimdi service account'un içine bakalım.
> kubectl auth can-i \
--list \
--as=system:serviceaccount:default \
-n dev
Resources Non-Resource URLs Resource Names Verbs
selfsubjectaccessreviews.authorization.k8s.io [] [] [create]
selfsubjectrulesreviews.authorization.k8s.io [] [] [create]
[/api/*] [] [get]
[/api] [] [get]
[/apis/*] [] [get]
[/apis] [] [get]
[/healthz] [] [get]
[/healthz] [] [get]
[/livez] [] [get]
[/livez] [] [get]
[/openapi/*] [] [get]
[/openapi] [] [get]
[/readyz] [] [get]
[/readyz] [] [get]
[/version/] [] [get]
[/version/] [] [get]
[/version] [] [get]
[/version] [] [get]
Hiç yorum yok:
Yorum Gönder