Giriş
Service account bir
token sağlar. Bu token Kubernetes tarafından doğrulama için kullanılır. Şeklen
şöyle
Account Tipleri
What Is Service Account in Kubernetes?
There are two types of account in Kubernetes
1. 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
So, a service account is an identity that is attached to the processes running within a pod.
Service Account yaratmak için
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: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: job-master
rules:
- apiGroups:
- batch
resources:
- cronjobs
verbs:
- 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
#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
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
User accounts are intended to be global. Names must be unique across all namespaces of a cluster. Service accounts are namespaced.
1. Default Service Account
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/serviceaccount
directory)
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 AGE
default 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]