什么是k8s的serviceAccount？

在 Kubernetes 中，ServiceAccount 是一種用于身份驗(yàn)證和授權(quán)的對(duì)象。它為 Pod 提供了一種身份，以便它們可以與 Kubernetes API 交互，并且可以通過(guò) Role 和 RoleBinding 為它們分配特定的權(quán)限。

ServiceAccount 是 Kubernetes 中的一種重要概念，它的實(shí)際使用場(chǎng)景包括：

• 訪問(wèn) Kubernetes API：ServiceAccount 為 Pod 提供了訪問(wèn) Kubernetes API 的憑據(jù)，使得它們可以查詢和修改 Kubernetes 中的資源。例如，一個(gè) Pod 可以使用 ServiceAccount 訪問(wèn) Kubernetes API 獲取其他 Pod 的信息，或者創(chuàng)建、更新、刪除其他資源。
• 認(rèn)證和授權(quán)：ServiceAccount 為 Pod 提供了一種身份，使得 Kubernetes 可以對(duì)其進(jìn)行認(rèn)證和授權(quán)。例如，Kubernetes 可以使用 ServiceAccount 來(lái)驗(yàn)證 Pod 是否有權(quán)限訪問(wèn)某個(gè)資源，并根據(jù) Role 和 RoleBinding 為其分配特定的權(quán)限。
• 安全性：ServiceAccount 可以幫助提高 Kubernetes 集群的安全性。通過(guò)為每個(gè) Pod 分配一個(gè)獨(dú)立的 ServiceAccount，并為其分配最小特權(quán)的權(quán)限，可以降低潛在的安全風(fēng)險(xiǎn)。
• 多租戶：ServiceAccount 可以幫助實(shí)現(xiàn) Kubernetes 中的多租戶。通過(guò)為每個(gè) Namespace 創(chuàng)建一個(gè)獨(dú)立的 ServiceAccount，并為其分配特定的權(quán)限，可以實(shí)現(xiàn)不同 Namespace 之間的隔離和安全性。

認(rèn)證和授權(quán)：ServiceAccount 為 Pod 提供了一種身份，使得 Kubernetes 可以對(duì)其進(jìn)行認(rèn)證和授權(quán)。例如，Kubernetes 可以使用 ServiceAccount 來(lái)驗(yàn)證 Pod 是否有權(quán)限訪問(wèn)某個(gè)資源，并根據(jù) Role 和 RoleBinding 為其分配特定的權(quán)限。

安全性：ServiceAccount 可以幫助提高 Kubernetes 集群的安全性。通過(guò)為每個(gè) Pod 分配一個(gè)獨(dú)立的 ServiceAccount，并為其分配最小特權(quán)的權(quán)限，可以降低潛在的安全風(fēng)險(xiǎn)。

多租戶：ServiceAccount 可以幫助實(shí)現(xiàn) Kubernetes 中的多租戶。通過(guò)為每個(gè) Namespace 創(chuàng)建一個(gè)獨(dú)立的 ServiceAccount，并為其分配特定的權(quán)限，可以實(shí)現(xiàn)不同 Namespace 之間的隔離和安全性。

為什么每一個(gè)ns下都有默認(rèn)的sa？

在 Kubernetes 中，每個(gè) namespace 下都有一個(gè)默認(rèn)的 ServiceAccount，原因如下：

簡(jiǎn)化配置：默認(rèn)的 ServiceAccount 使得用戶無(wú)需為每個(gè) Pod 創(chuàng)建一個(gè)新的 ServiceAccount，從而簡(jiǎn)化了配置。如果 Pod 沒(méi)有指定 ServiceAccount，它將自動(dòng)關(guān)聯(lián)到默認(rèn)的 ServiceAccount。

容器運(yùn)行時(shí)身份：ServiceAccount 提供了一種將身份信息（如 API 訪問(wèn)憑據(jù)）與 Pod 關(guān)聯(lián)的方法。默認(rèn)的 ServiceAccount 為 Pod 提供了基本的身份信息，以便它們可以與 Kubernetes API 交互。

安全性：默認(rèn)的 ServiceAccount 通常具有較少的權(quán)限，這有助于遵循最小特權(quán)原則。這意味著，如果 Pod 不需要訪問(wèn) Kubernetes API 的特定資源，它可以使用默認(rèn)的 ServiceAccount，從而降低潛在的安全風(fēng)險(xiǎn)。

易于管理：默認(rèn)的 ServiceAccount 使得集群管理員可以更輕松地管理和控制對(duì) Kubernetes API 的訪問(wèn)。例如，管理員可以通過(guò)修改默認(rèn) ServiceAccount 的權(quán)限來(lái)限制或擴(kuò)展某個(gè) namespace 下所有 Pod 的訪問(wèn)權(quán)限。

總之，默認(rèn)的 ServiceAccount 是 Kubernetes 中的一種設(shè)計(jì)，旨在簡(jiǎn)化配置、提供基本的身份信息、增強(qiáng)安全性并便于管理。然而，在實(shí)際應(yīng)用中，根據(jù)需要?jiǎng)?chuàng)建特定的 ServiceAccount 并為其分配適當(dāng)?shù)臋?quán)限是一種更好的做法。

default sa yaml

k get secret default-token-lnzs9 -oyaml
apiVersion: v1
data:
  ca.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUR2akNDQXFhZ0F3SUJBZ0lVVFZZeWZ0VDFBdnQ1ZHlORmM4WUN...
  HU4NkZ0bTNyRkNaNUY3N1FmTVpCNU9hYXE2TkRDRwp3ems9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
  namespace: ZGVmYXVsdA==
  token: ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkNJNkltcEdjRkkwWlRSRU55MW1NeTF4YWt0U1pYQm9Sems0U1dJd2RHMTV
。。。
  xQUJsdVlnSGJva3ZB
kind: Secret
metadata:
  annotations:
    kubernetes.io/service-account.name: default
    kubernetes.io/service-account.uid: b90818be-0587-4a7a-8abb-c0b214cdaba0
  creationTimestamp: "2022-06-26T07:04:38Z"
  name: default-token-lnzs9
  namespace: default
  resourceVersion: "11436"
  uid: 37c38aaa-bd9d-4beb-abf9-cdc94bcc697a
type: kubernetes.io/service-account-token

默認(rèn)的sa下都會(huì)掛一個(gè)secret，這個(gè)secret是從哪里來(lái)的？

在 Kubernetes 中創(chuàng)建一個(gè)新的 Namespace 時(shí)，系統(tǒng)會(huì)自動(dòng)為該 Namespace 下的默認(rèn) ServiceAccount 創(chuàng)建一個(gè)關(guān)聯(lián)的 Secret。這個(gè) Secret 是用于存儲(chǔ)訪問(wèn) Kubernetes API 的憑據(jù)的，通常包含一個(gè) token 和一個(gè) CA 證書。這個(gè) Secret 的來(lái)源如下：

Kubernetes 控制平面的 Token Controller 自動(dòng)創(chuàng)建并管理這個(gè) Secret。當(dāng)創(chuàng)建一個(gè)新的 ServiceAccount 時(shí)，Token Controller 會(huì)生成一個(gè)新的 token，并將其存儲(chǔ)在一個(gè)新的 Secret 中。

該 Secret 會(huì)被自動(dòng)關(guān)聯(lián)到對(duì)應(yīng)的 ServiceAccount。Secret 的類型為 kubernetes.io/service-account-token，并且在 Secret 的 annotations 字段中包含了關(guān)聯(lián)的 ServiceAccount 信息。

當(dāng)創(chuàng)建一個(gè)使用該 ServiceAccount 的 Pod 時(shí)，Kubernetes 會(huì)自動(dòng)將這個(gè) Secret 掛載到 Pod 的容器中。默認(rèn)情況下，Secret 會(huì)被掛載到 /var/run/secrets/kubernetes.io/serviceaccount 目錄下。容器內(nèi)的應(yīng)用程序可以使用這個(gè) token 和 CA 證書與 Kubernetes API 交互。

要查看默認(rèn) ServiceAccount 關(guān)聯(lián)的 Secret，可以使用以下命令：

kubectl get serviceaccounts default -o jsonpath='{.secrets[0``].name}' -n <namespace>

將 替換為實(shí)際的 Namespace 名稱。然后，使用以下命令查看 Secret 的詳細(xì)信息：

kubectl get secret <secret_name> -o yaml -n <namespace>

將 <secret_name> 替換為上一步獲取到的 Secret 名稱，將 替換為實(shí)際的 Namespace 名稱。

一道關(guān)于RBAC的CKA考題

假設(shè)我們有一個(gè)運(yùn)行在 Kubernetes 中的 Web 應(yīng)用程序，它需要訪問(wèn) Kubernetes API 來(lái)獲取其他 Pod 的信息。

為了實(shí)現(xiàn)這個(gè)功能，我們可以創(chuàng)建一個(gè) ServiceAccount，并為其分配訪問(wèn) Kubernetes API 的權(quán)限。具體步驟如下：

1、創(chuàng)建一個(gè)新的 ServiceAccount

kubectl create serviceaccount myapp-sa

2、創(chuàng)建一個(gè)新的 Role

用于授予 ServiceAccount 訪問(wèn) Kubernetes API 的權(quán)限：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: myapp-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"] # 注意只有g(shù)et和list的權(quán)限，并不需要update的權(quán)限

3、創(chuàng)建一個(gè)新的 RoleBinding

將 ServiceAccount 和 Role 關(guān)聯(lián)起來(lái)：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: myapp-rolebinding
subjects:
- kind: ServiceAccount
  name: myapp-sa
roleRef:
  kind: Role
  name: myapp-role
  apiGroup: rbac.authorization.k8s.io

4、在 Pod 中使用 ServiceAccount

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
spec:
  serviceAccountName: myapp-sa
  containers:
  - name: myapp-container
    image: myapp-image

在這個(gè)例子中，我們創(chuàng)建了一個(gè)名為 myapp-sa 的 ServiceAccount，并為其分配了訪問(wèn) Kubernetes API 的權(quán)限。然后，我們創(chuàng)建了一個(gè)名為 myapp-role 的 Role，并將其與 ServiceAccount 關(guān)聯(lián)起來(lái)。最后，我們?cè)?Pod 中使用了這個(gè) ServiceAccount。

這樣，我們的 Web 應(yīng)用程序就可以使用這個(gè) ServiceAccount 訪問(wèn) Kubernetes API，獲取其他 Pod 的信息。同時(shí)，由于我們?yōu)?ServiceAccount 分配了最小特權(quán)的權(quán)限，可以降低潛在的安全風(fēng)險(xiǎn)。

role和rolebinding的核心

role是定義一組權(quán)限列表

rolebinding有兩個(gè)obj:

• roleRef : 綁定哪個(gè)role？
• subjects： 給誰(shuí)綁定的問(wèn)題 可以是user、可以是sa也可以是group

如果遇到不懂怎么寫就是explain。

練習(xí)一

只能使用官網(wǎng)的情況下，完成下面和這個(gè)需求:

Create a new ServiceAccount processor in Namespace project-hamster. Create a Role and RoleBinding, both named processor as well. These should allow the new SA to only create Secrets and ConfigMaps in that Namespace.

提示; 可以使用kubectl 命令create role、create rolebinding

練習(xí)二

讓alice這個(gè)用戶可以創(chuàng)建sa:

創(chuàng)建一個(gè)新的 Role，用于控制 ServiceAccount 的創(chuàng)建：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: serviceaccount-creator
rules:
- apiGroups: [""]
  resources: ["serviceaccounts"]
  verbs: ["create"]

創(chuàng)建一個(gè)新的 RoleBinding，將 Role 和用戶或組關(guān)聯(lián)起來(lái)：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: serviceaccount-creator-binding
subjects:
- kind: User
  name: alice
roleRef:
  kind: Role
  name: serviceaccount-creator
  apiGroup: rbac.authorization.k8s.io

在這個(gè)例子中，我們創(chuàng)建了一個(gè)名為 serviceaccount-creator 的 Role，用于控制 ServiceAccount 的創(chuàng)建。然后，我們創(chuàng)建了一個(gè)名為 serviceaccount-creator-binding 的 RoleBinding，將 Role 和用戶 alice 關(guān)聯(lián)起來(lái)。

這樣，用戶 alice 就可以使用 kubectl create serviceaccount 命令創(chuàng)建新的 ServiceAccount。其他用戶或組如果沒(méi)有被授權(quán)，將無(wú)法創(chuàng)建新的 ServiceAccount。

需要注意的是，RBAC 可以用于控制 ServiceAccount 的創(chuàng)建和使用，但不能直接控制 ServiceAccount 的訪問(wèn)權(quán)限。要為 ServiceAccount 分配訪問(wèn)權(quán)限，需要使用 Role 和 RoleBinding。

到此這篇關(guān)于kubernetes為何需要默認(rèn)的serviceaccount？的文章就介紹到這了,更多相關(guān)kubernetes serviceaccount內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論