kubernetes為什么需要默認的serviceaccount

這篇文章主要介紹“kubernetes為什么需要默認的serviceaccount”的相關知識，小編通過實際案例向大家展示操作過程，操作方法簡單快捷，實用性強，希望這篇“kubernetes為什么需要默認的serviceaccount”文章能幫助大家解決問題。

什么是k8s的serviceAccount？

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

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

• 訪問 Kubernetes API：ServiceAccount 為 Pod 提供了訪問 Kubernetes API 的憑據，使得它們可以查詢和修改 Kubernetes 中的資源。例如，一個 Pod 可以使用 ServiceAccount 訪問 Kubernetes API 獲取其他 Pod 的信息，或者創建、更新、刪除其他資源。

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

• 安全性：ServiceAccount 可以幫助提高 Kubernetes 集群的安全性。通過為每個 Pod 分配一個獨立的 ServiceAccount，并為其分配最小特權的權限，可以降低潛在的安全風險。

• 多租戶：ServiceAccount 可以幫助實現 Kubernetes 中的多租戶。通過為每個 Namespace 創建一個獨立的 ServiceAccount，并為其分配特定的權限，可以實現不同 Namespace 之間的隔離和安全性。

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

安全性：ServiceAccount 可以幫助提高 Kubernetes 集群的安全性。通過為每個 Pod 分配一個獨立的 ServiceAccount，并為其分配最小特權的權限，可以降低潛在的安全風險。

多租戶：ServiceAccount 可以幫助實現 Kubernetes 中的多租戶。通過為每個 Namespace 創建一個獨立的 ServiceAccount，并為其分配特定的權限，可以實現不同 Namespace 之間的隔離和安全性。

為什么每一個ns下都有默認的sa？

在 Kubernetes 中，每個 namespace 下都有一個默認的 ServiceAccount，原因如下：

簡化配置：默認的 ServiceAccount 使得用戶無需為每個 Pod 創建一個新的 ServiceAccount，從而簡化了配置。如果 Pod 沒有指定 ServiceAccount，它將自動關聯到默認的 ServiceAccount。

容器運行時身份：ServiceAccount 提供了一種將身份信息（如 API 訪問憑據）與 Pod 關聯的方法。默認的 ServiceAccount 為 Pod 提供了基本的身份信息，以便它們可以與 Kubernetes API 交互。

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

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

總之，默認的 ServiceAccount 是 Kubernetes 中的一種設計，旨在簡化配置、提供基本的身份信息、增強安全性并便于管理。然而，在實際應用中，根據需要創建特定的 ServiceAccount 并為其分配適當的權限是一種更好的做法。

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

默認的sa下都會掛一個secret，這個secret是從哪里來的？

在 Kubernetes 中創建一個新的 Namespace 時，系統會自動為該 Namespace 下的默認 ServiceAccount 創建一個關聯的 Secret。這個 Secret 是用于存儲訪問 Kubernetes API 的憑據的，通常包含一個 token 和一個 CA 證書。這個 Secret 的來源如下：

Kubernetes 控制平面的 Token Controller 自動創建并管理這個 Secret。當創建一個新的 ServiceAccount 時，Token Controller 會生成一個新的 token，并將其存儲在一個新的 Secret 中。

該 Secret 會被自動關聯到對應的 ServiceAccount。Secret 的類型為 kubernetes.io/service-account-token，并且在 Secret 的 annotations 字段中包含了關聯的 ServiceAccount 信息。

當創建一個使用該 ServiceAccount 的 Pod 時，Kubernetes 會自動將這個 Secret 掛載到 Pod 的容器中。默認情況下，Secret 會被掛載到 /var/run/secrets/kubernetes.io/serviceaccount 目錄下。容器內的應用程序可以使用這個 token 和 CA 證書與 Kubernetes API 交互。

要查看默認 ServiceAccount 關聯的 Secret，可以使用以下命令：

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

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

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

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

一道關于RBAC的CKA考題

假設我們有一個運行在 Kubernetes 中的 Web 應用程序，它需要訪問 Kubernetes API 來獲取其他 Pod 的信息。

為了實現這個功能，我們可以創建一個 ServiceAccount，并為其分配訪問 Kubernetes API 的權限。具體步驟如下：

1、創建一個新的 ServiceAccount

kubectl create serviceaccount myapp-sa

2、創建一個新的 Role

用于授予 ServiceAccount 訪問 Kubernetes API 的權限：

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

3、創建一個新的 RoleBinding

將 ServiceAccount 和 Role 關聯起來：

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

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

這樣，我們的 Web 應用程序就可以使用這個 ServiceAccount 訪問 Kubernetes API，獲取其他 Pod 的信息。同時，由于我們為 ServiceAccount 分配了最小特權的權限，可以降低潛在的安全風險。

role和rolebinding的核心

role是定義一組權限列表

rolebinding有兩個obj:

• roleRef : 綁定哪個role？

• subjects： 給誰綁定的問題 可以是user、可以是sa也可以是group

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

練習一

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

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

練習二

讓alice這個用戶可以創建sa:

創建一個新的 Role，用于控制 ServiceAccount 的創建：

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

創建一個新的 RoleBinding，將 Role 和用戶或組關聯起來：

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

在這個例子中，我們創建了一個名為 serviceaccount-creator 的 Role，用于控制 ServiceAccount 的創建。然后，我們創建了一個名為 serviceaccount-creator-binding 的 RoleBinding，將 Role 和用戶 alice 關聯起來。

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

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

關于“kubernetes為什么需要默認的serviceaccount”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識，可以關注億速云行業資訊頻道，小編每天都會為大家更新不同的知識點。