kubernetes的Service Account
- Service account作用
Service account是爲了方便Pod裏面的進程調用Kubernetes API或其他外部服務。 - Service account使用場景
運行在pod裏的進程需要調用Kubernetes API以及非Kubernetes API的其它服務。Service Account它並不是給kubernetes集羣的用戶使用的,而是給pod裏面的進程使用的,它爲pod提供必要的身份認證。 - 與User account區別
(1)User account是爲人設計的,而service account則是爲了Pod中的進程;
(2)User account是跨namespace的,而service account則是僅侷限它所在的namespace; - 實戰
#定義namespace:test cat >> test.yaml << EOF apiVersion: v1 kind: Namespace metadata: name: test labels: name: test
#創建namespace:test kubectl create -f ./test.yaml
#查看命名空間test的sa kubectl get sa -n test NAME SECRETS AGE default 1 3h ##說明: (1)如果kubernetes開啓了ServiceAccount(–admission_control=…, ServiceAccount,… )那麼會在每個namespace下面都會創建一個默認的default 的sa。如上命令查看的default ! (2)ServiceAccount默認是開啓的。
#查看命名空間test生成的default kubectl get sa default -o yaml -n test apiVersion: v1 kind: ServiceAccount metadata: creationTimestamp: 2018-05-31T06:21:10Z name: default namespace: test resourceVersion: "45560" selfLink: /api/v1/namespaces/test/serviceaccounts/default uid: cf57c735-649a-11e8-adc5-000c290a7d06 secrets: - name: default-token-ccf9m ##說明: (1)當用戶再該namespace下創建pod的時候都會默認使用這個sa; (2)每個Pod在創建後都會自動設置spec.serviceAccount爲default(除非指定 了其他ServiceAccout); (3)每個container啓動後都會掛載對應的token和ca.crt到/var/run/secrets/ kubernetes.io/serviceaccount/。
#創建deploy cat >> nginx_deploy.yaml << EOF apiVersion: extensions/v1beta1 kind: Deployment metadata: name: nginx-test namespace: test spec: replicas: 2 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80
#查看生成的Pods kubectl get po -n test NAME READY STATUS RESTARTS AGE nginx-test-75675f5897-7l5bc 1/1 Running 0 1h nginx-test-75675f5897-b7pcn 1/1 Running 0 1h
#查看其中一個Pod的詳細信息,如:nginx-test-75675f5897-7l5bc kubectl describe po nginx-test-75675f5897-7l5bc -n test ##其中default-token-ccf9m,請留意! Environment: <none> Mounts: /var/run/secrets/kubernetes.io/serviceaccount from default-token-ccf9m (ro) Conditions: Type Status Initialized True Ready True PodScheduled True Volumes: default-token-ccf9m: Type: Secret (a volume populated by a Secret) SecretName: default-token-ccf9m ##說明: (1)每個Pod在創建後都會自動設置spec.serviceAccount爲default(除非指定 了其他ServiceAccout); (2)每個container啓動後都會掛載對應的token和ca.crt到/var/run/secrets/ kubernetes.io/serviceaccount/。
#進入其中一個Pod的容器內,如:nginx-test-75675f5897-7l5bc kubectl exec -it nginx-test-75675f5897-7l5bc /bin/bash --namespace=test ##在容器內執行: ls -l /var/run/secrets/kubernetes.io/serviceaccount/ lrwxrwxrwx 1 root root 13 May 31 08:15 ca.crt -> ..data/ca.crt lrwxrwxrwx 1 root root 16 May 31 08:15 namespace -> ..data/namespace lrwxrwxrwx 1 root root 12 May 31 08:15 token -> ..data/token ##說明: 可以看到已將ca.crt 、namespace和token放到容器內了,那麼這個容器就 可以通過https的請求訪問apiserver了。
- 手動創建Service Account
#編輯heapster_test.yaml文件 cat >> heapster_test.yaml <<EOF apiVersion: v1 kind: ServiceAccount metadata: name: heapster namespace: test
#創建Service Account:heapster kubectl create -f heapster_test.yaml serviceaccount "heapster" created
#查看Service Account:heapster kubectl get sa -o yaml -n test ##主要內容如下: secrets: - name: heapster-token-7xrlg
-
Service Account鑑權
Service Account爲服務提供了一種方便的認知機制,但它不關心授權的問題。可以配合RBAC來爲Service Account鑑權:(1)配置--authorization-mode=RBAC和--runtime-config=rbac.authorization.k 8s.io/v1alpha1 (2)配置--authorization-rbac-super-user=admin (3)定義Role、ClusterRole、RoleBinding或ClusterRoleBinding
#實戰
我們在Kubernetes Dashboard1.8.3部署中,碰到首次登入出現訪問權限報錯的問題,原因就是ServiceAccount的創建問題。cat >> kube-dashboard-access.yaml << EOF apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRoleBinding metadata: name: kubernetes-dashboard labels: k8s-app: kubernetes-dashboard roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - kind: ServiceAccount name: kubernetes-dashboard namespace: kube-system
- 參考文章
https://www.ctolib.com/docs/sfile/kubernetes-handbook/architecture/serviceaccount.html
https://blog.csdn.net/u010278923/article/details/72857928