什么是k8s的serviceAccount？

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

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

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

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

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

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

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

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

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

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

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

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

總之，默認(rèn)的 ServiceAccount 是 Kubernetes 中的一種設(shè)計(jì)，旨在簡化配置、提供基本的身份信息、增強(qiáng)安全性并便于管理。然而，在實(shí)際應(yīng)用中，根據(jù)需要創(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下都會掛一個secret，這個secret是從哪里來的？

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

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

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

當(dāng)創(chuàng)建一個使用該 ServiceAccount 的 Pod 時(shí)，Kubernetes 會自動將這個 Secret 掛載到 Pod 的容器中。默認(rèn)情況下，Secret 會被掛載到 /var/run/secrets/kubernetes.io/serviceaccount 目錄下。容器內(nèi)的應(yīng)用程序可以使用這個 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è)我們有一個運(yùn)行在 Kubernetes 中的 Web 應(yīng)用程序，它需要訪問 Kubernetes API 來獲取其他 Pod 的信息。

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

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

kubectl create serviceaccount myapp-sa

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

用于授予 ServiceAccount 訪問 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)建一個新的 RoleBinding

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

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

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

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

role和rolebinding的核心

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

rolebinding有兩個obj:

• roleRef : 綁定哪個role？
• subjects： 給誰綁定的問題 可以是user、可以是sa也可以是group

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

練習(xí)一

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

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這個用戶可以創(chuàng)建sa:

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

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

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

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

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

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

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

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

最新評論