目錄
- 什么是k8s的serviceAccount？
- 為什么每一個ns下都有默認的sa？
- default sa yaml
- 默認的sa下都會掛一個secret，這個secret是從哪里來的？
- 一道關(guān)于RBAC的CKA考題
- 1、創(chuàng)建一個新的 ServiceAccount
- 2、創(chuàng)建一個新的 Role
- 3、創(chuàng)建一個新的 RoleBinding
- 4、在 Pod 中使用 ServiceAccount
- role和rolebinding的核心
- 練習一
- 練習二
什么是k8s的serviceAccount？
在 Kubernetes 中，ServiceAccount 是一種用于身份驗證和授權(quán)的對象。它為 Pod 提供了一種身份，以便它們可以與 Kubernetes API 交互，并且可以通過 Role 和 RoleBinding 為它們分配特定的權(quán)限。
ServiceAccount 是 Kubernetes 中的一種重要概念，它的實際使用場景包括：
- 訪問 Kubernetes API：ServiceAccount 為 Pod 提供了訪問 Kubernetes API 的憑據(jù)，使得它們可以查詢和修改 Kubernetes 中的資源。例如，一個 Pod 可以使用 ServiceAccount 訪問 Kubernetes API 獲取其他 Pod 的信息，或者創(chuàng)建、更新、刪除其他資源。
- 認證和授權(quán)：ServiceAccount 為 Pod 提供了一種身份，使得 Kubernetes 可以對其進行認證和授權(quán)。例如，Kubernetes 可以使用 ServiceAccount 來驗證 Pod 是否有權(quán)限訪問某個資源，并根據(jù) Role 和 RoleBinding 為其分配特定的權(quán)限。
- 安全性：ServiceAccount 可以幫助提高 Kubernetes 集群的安全性。通過為每個 Pod 分配一個獨立的 ServiceAccount，并為其分配最小特權(quán)的權(quán)限，可以降低潛在的安全風險。
- 多租戶：ServiceAccount 可以幫助實現(xiàn) Kubernetes 中的多租戶。通過為每個 Namespace 創(chuàng)建一個獨立的 ServiceAccount，并為其分配特定的權(quán)限，可以實現(xiàn)不同 Namespace 之間的隔離和安全性。
認證和授權(quán)：ServiceAccount 為 Pod 提供了一種身份，使得 Kubernetes 可以對其進行認證和授權(quán)。例如，Kubernetes 可以使用 ServiceAccount 來驗證 Pod 是否有權(quán)限訪問某個資源，并根據(jù) Role 和 RoleBinding 為其分配特定的權(quán)限。
安全性：ServiceAccount 可以幫助提高 Kubernetes 集群的安全性。通過為每個 Pod 分配一個獨立的 ServiceAccount，并為其分配最小特權(quán)的權(quán)限，可以降低潛在的安全風險。
多租戶：ServiceAccount 可以幫助實現(xiàn) Kubernetes 中的多租戶。通過為每個 Namespace 創(chuàng)建一個獨立的 ServiceAccount，并為其分配特定的權(quán)限，可以實現(xiàn)不同 Namespace 之間的隔離和安全性。
為什么每一個ns下都有默認的sa？
在 Kubernetes 中，每個 namespace 下都有一個默認的 ServiceAccount，原因如下：
簡化配置：默認的 ServiceAccount 使得用戶無需為每個 Pod 創(chuàng)建一個新的 ServiceAccount，從而簡化了配置。如果 Pod 沒有指定 ServiceAccount，它將自動關(guān)聯(lián)到默認的 ServiceAccount。
容器運行時身份：ServiceAccount 提供了一種將身份信息（如 API 訪問憑據(jù)）與 Pod 關(guān)聯(lián)的方法。默認的 ServiceAccount 為 Pod 提供了基本的身份信息，以便它們可以與 Kubernetes API 交互。
安全性：默認的 ServiceAccount 通常具有較少的權(quán)限，這有助于遵循最小特權(quán)原則。這意味著，如果 Pod 不需要訪問 Kubernetes API 的特定資源，它可以使用默認的 ServiceAccount，從而降低潛在的安全風險。
易于管理：默認的 ServiceAccount 使得集群管理員可以更輕松地管理和控制對 Kubernetes API 的訪問。例如，管理員可以通過修改默認 ServiceAccount 的權(quán)限來限制或擴展某個 namespace 下所有 Pod 的訪問權(quán)限。
總之，默認的 ServiceAccount 是 Kubernetes 中的一種設(shè)計，旨在簡化配置、提供基本的身份信息、增強安全性并便于管理。然而，在實際應(yīng)用中，根據(jù)需要創(chuàng)建特定的 ServiceAccount 并為其分配適當?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
默認的sa下都會掛一個secret，這個secret是從哪里來的？
在 Kubernetes 中創(chuàng)建一個新的 Namespace 時，系統(tǒng)會自動為該 Namespace 下的默認 ServiceAccount 創(chuàng)建一個關(guān)聯(lián)的 Secret。這個 Secret 是用于存儲訪問 Kubernetes API 的憑據(jù)的，通常包含一個 token 和一個 CA 證書。這個 Secret 的來源如下：
Kubernetes 控制平面的 Token Controller 自動創(chuàng)建并管理這個 Secret。當創(chuàng)建一個新的 ServiceAccount 時，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 信息。
當創(chuàng)建一個使用該 ServiceAccount 的 Pod 時，Kubernetes 會自動將這個 Secret 掛載到 Pod 的容器中。默認情況下，Secret 會被掛載到 /var/run/secrets/kubernetes.io/serviceaccount 目錄下。容器內(nèi)的應(yīng)用程序可以使用這個 token 和 CA 證書與 Kubernetes API 交互。
要查看默認 ServiceAccount 關(guān)聯(lián)的 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 名稱。
一道關(guān)于RBAC的CKA考題
假設(shè)我們有一個運行在 Kubernetes 中的 Web 應(yīng)用程序，它需要訪問 Kubernetes API 來獲取其他 Pod 的信息。
為了實現(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 的信息。同時，由于我們?yōu)?ServiceAccount 分配了最小特權(quán)的權(quán)限，可以降低潛在的安全風險。
role和rolebinding的核心
role是定義一組權(quán)限列表
rolebinding有兩個obj:
- roleRef : 綁定哪個role？
- subjects： 給誰綁定的問題 可以是user、可以是sa也可以是group
如果遇到不懂怎么寫就是explain。
練習一
只能使用官網(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
練習二
讓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。
