访问控制1

主要内容

1. ServiceAccount
2. Role和ClusterRole

---

预备知识

用户使用kubectl、客户端库或者rest请求访问kubernetes
API。人类用户和kubernetes服务账户都可以被鉴权访问API。当请求达到API时，它会经历多个阶段，如下图所示：

访问控制是一种机制，用于限制对系统、资源或数据的访问权限。它是信息安全的重要组成部分，可以确保只有经过授权的用户或系统可以访问敏感信息或执行特定操作。

访问控制通常涉及以下几个方面：

1. 身份验证：验证用户的身份以确保他们是合法的用户。常见的身份验证方式包括用户名和密码、指纹识别、智能卡等。

2. 授权：一旦用户通过身份验证，系统需要确定他们有权访问哪些资源或执行哪些操作。授权可以基于用户的角色、组织结构、访问策略等进行。

3. 权限管理：权限管理确定了用户在系统中可以执行的具体操作。这些权限可以是读取、写入、修改、删除等。权限管理通常与角色管理和访问策略相结合，以确保用户只能执行他们被授权的操作。

4. 审计和日志记录：审计和日志记录是跟踪和记录用户访问行为的过程。它可以用于监控系统的安全性，检测潜在的安全威胁，并提供法律证据。

访问控制在各种系统和领域中都有广泛的应用。例如，在计算机网络中，访问控制可以用于限制对网络资源的访问。在操作系统中，访问控制可以用于限制对文件和目录的访问。在数据库中，访问控制可以用于限制对敏感数据的访问。

访问控制的主要目标是确保系统的机密性、完整性和可用性。机密性确保只有授权用户可以访问敏感信息，完整性确保只有授权用户可以修改数据，可用性确保授权用户可以正常使用系统。

总之，访问控制是一种重要的安全机制，它可以保护系统和数据免受未经授权的访问和潜在的安全威胁。通过合理的身份验证、授权、权限管理和审计，可以建立一个安全可靠的访问控制系统。

---

一.ServiceAccount

Service account 是为了方便 Pod 里面的进程调用 Kubernetes API 或 其他外部服务而设计的。每个 namespace 都会自动创建一个 default service account.
Token controller 检测 service account 的创建，并为它们创建 secret(token)并与APIServer 进行交互。
在创建 Pod 时，如果没有指定服务账户，Pod 会被指定给命名空间中的 default 服务账户。container 启动后都会挂载该 service account 的 token 和 ca.crt 到如下位置：
/var/run/secrets/kubernetes.io/serviceaccount/ .
pod 和 apiserver 之间进行通信的账号称为 serviceAccountName.

ServiceAccount是Kubernetes中用于身份验证和授权的机制。它为Pod提供了一组凭据，用于与Kubernetes API服务器进行通信，并访问其他Kubernetes资源。

ServiceAccount是一种Kubernetes对象，可以在Kubernetes集群中创建和管理。每个ServiceAccount都有一个唯一的名称和一个与之关联的Secret，其中包含了用于身份验证和授权的凭据。Pod可以通过挂载ServiceAccount中的Secret来获取这些凭据，以便与Kubernetes API服务器进行通信。

ServiceAccount可以用于以下场景：

1. 访问Kubernetes API：Pod可以使用ServiceAccount中的凭据来与Kubernetes API服务器进行通信，例如创建、删除、修改Kubernetes资源。

2. 访问其他资源：Pod可以使用ServiceAccount中的凭据来访问其他Kubernetes资源，例如Secret、ConfigMap、PersistentVolumeClaim等。

3. 访问外部资源：Pod可以使用ServiceAccount中的凭据来访问外部资源，例如云服务、数据库等。

ServiceAccount的用法如下：

1. 创建ServiceAccount：可以使用kubectl命令或YAML文件创建ServiceAccount对象。

2. 分配ServiceAccount：可以将ServiceAccount分配给Pod，以便Pod可以使用其中的凭据进行身份验证和授权。可以使用PodSpec中的serviceAccountName字段指定要使用的ServiceAccount。

3. 挂载ServiceAccount中的Secret：可以在Pod中通过挂载ServiceAccount中的Secret来获取其中的凭据。可以使用volumeMounts字段指定要挂载的Secret。

4. 配置RBAC：可以使用Role-Based Access Control（RBAC）来控制哪些ServiceAccount可以访问哪些资源。可以使用Role、ClusterRole、RoleBinding和ClusterRoleBinding对象来定义和管理RBAC规则。

总之，ServiceAccount是Kubernetes中用于身份验证和授权的重要机制。它为Pod提供了一组凭据，用于与Kubernetes API服务器进行通信，并访问其他Kubernetes资源。通过合理使用ServiceAccount和RBAC，可以建立一个安全可靠的Kubernetes集群。

1.示例：在一个名为acctests的namespace中，创建一个名为udbs的serviceAccount

代码如下（示例）:

kubectl create namespace acctest
kubectl -n acctest create serviceaccount udbs
kubectl -n acctest get serviceaccounts udbs

1
2
3
4

kubectl -n acctest describe serviceaccounts udbs
1

2.解释

以下是对每个命令的详细解释：

1. `kubectl create namespace acctest`：这个命令创建了一个名为"acctest"的命名空间。命名空间是Kubernetes中用于隔离和组织资源的一种机制。

2. `kubectl -n acctest create serviceaccount udbs`：这个命令在"acctest"命名空间中创建了一个名为"udbs"的ServiceAccount。ServiceAccount是Kubernetes中用于身份验证和授权的机制。

3. `kubectl -n acctest get serviceaccounts udbs`：这个命令在"acctest"命名空间中获取名为"udbs"的ServiceAccount的详细信息。它会显示ServiceAccount的名称、创建时间和相关的Secret。

4. `kubectl -n acctest describe serviceaccounts udbs`：这个命令在"acctest"命名空间中获取名为"udbs"的ServiceAccount的详细描述。它会显示ServiceAccount的名称、创建时间、相关的Secret以及与之关联的权限。

这些命令的目的是在"acctest"命名空间中创建一个名为"udbs"的ServiceAccount，并获取它的详细信息和描述。这样可以验证ServiceAccount是否成功创建，并查看与之关联的Secret和权限。
1
2
3
4
5
6
7
8
9
10
11

---

二.Role和ClusterRole

Role和ClusterRole是Kubernetes中用于定义权限的对象。它们用于控制ServiceAccount对特定资源的访问权限。

Role用于在单个命名空间中定义权限，而ClusterRole用于在整个集群范围内定义权限。Role和ClusterRole可以与RoleBinding和ClusterRoleBinding对象一起使用，来将权限分配给ServiceAccount。

以下是Role和ClusterRole的详细解释及用法：

1. Role（角色）：

   • Role是Kubernetes中的一种对象，用于在单个命名空间中定义权限。
   • Role定义了一组规则（rules），每个规则指定了对特定资源的访问权限（例如：创建、读取、更新、删除）。
   • Role只能在其所属的命名空间中生效。
   • 可以使用kubectl命令或YAML文件创建Role对象。
   • RoleBinding对象用于将Role与ServiceAccount关联起来，从而将权限分配给ServiceAccount。

2. ClusterRole（集群角色）：

   • ClusterRole是Kubernetes中的一种对象，用于在整个集群范围内定义权限。
   • ClusterRole定义了一组规则（rules），每个规则指定了对特定资源的访问权限（例如：创建、读取、更新、删除）。
   • ClusterRole可以在所有命名空间中生效。
   • 可以使用kubectl命令或YAML文件创建ClusterRole对象。
   • ClusterRoleBinding对象用于将ClusterRole与ServiceAccount关联起来，从而将权限分配给ServiceAccount。

用法示例：

1. 创建Role：

 apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: my-role
     namespace: my-namespace
   rules:
   - apiGroups: [""]
     resources: ["pods"]
     verbs: ["get", "list", "create", "delete"]
1
2
3
4
5
6
7
8
9

1

2. 创建ClusterRole：

  apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: my-cluster-role
   rules:
   - apiGroups: [""]
     resources: ["pods"]
     verbs: ["get", "list", "create", "delete"]
1
2
3
4
5
6
7
8

3. 创建RoleBinding：

 apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: my-role-binding
     namespace: my-namespace
   roleRef:
     kind: Role
     name: my-role
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - kind: ServiceAccount
     name: my-service-account
     namespace: my-namespace
1
2
3
4
5
6
7
8
9
10
11
12
13

4. 创建ClusterRoleBinding：

  apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: my-cluster-role-binding
   roleRef:
     kind: ClusterRole
     name: my-cluster-role
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - kind: ServiceAccount
     name: my-service-account
     namespace: my-namespace
1
2
3
4
5
6
7
8
9
10
11
12

这些示例展示了如何创建Role、ClusterRole、RoleBinding和ClusterRoleBinding对象，并将权限分配给ServiceAccount。通过合理使用Role和ClusterRole，可以实现对Kubernetes资源的精确控制和权限管理。

1.在名为test的namespace中创建一个名为test-role的角色,以及创建一个名为test-clusterrole的集群角色。

代码如下（示例）:

kubectl -n test create role --resource=pod --verb=get test-role
kubectl -n test delete role test-role
1
2

2.YAML方法

代码如下（示例）:

cat > role.yml <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
 name: test-role
 namespace: test
rules:
- apiGroups:
 - ""
 resources:
 - pods
 verbs:
 - get
EOF
1
2
3
4
5
6
7
8
9
10
11
12
13
14

kubectl create -f role.yml
kubectl describe role -n test test-role
1
2

3.将创建的test-role角色绑定到serviceaccount的服务账号udbs

代码如下（示例）:

kubectl -n test create rolebinding --role=test-role --serviceaccount=test:udbs udbs-binding
kubectl -n test describe rolebinding udbs-binding

1
2
3

4.测试权限

代码如下（示例）:

kubectl -n test auth can-i create pods --as=system:serviceaccount:test:udbs
kubectl -n test auth can-i get pods --as=system:serviceaccount:test:udbs
1
2

5.解释

1. `kubectl -n test create role --resource=pod --verb=get test-role`：这个命令在"test"命名空间中创建一个名为"test-role"的Role对象。该Role对象的规则指定了对"pods"资源的"get"权限。

2. `kubectl -n test delete role test-role`：这个命令在"test"命名空间中删除名为"test-role"的Role对象。

3. `kubectl -n test create rolebinding --role=test-role --serviceaccount=test:udbs udbs-binding`：这个命令在"test"命名空间中创建一个名为"udbs-binding"的RoleBinding对象。该RoleBinding对象将"test-role"角色与"test:udbs" ServiceAccount关联起来。

4. `kubectl -n test describe rolebinding udbs-binding`：这个命令在"test"命名空间中获取名为"udbs-binding"的RoleBinding对象的详细描述信息。它会显示RoleBinding对象的名称、关联的Role、关联的ServiceAccount等信息。

5. `kubectl -n test auth can-i create pods --as=system:serviceaccount:test:udbs`：这个命令用于检查"test:udbs" ServiceAccount是否具有在"test"命名空间中创建pods的权限。它会返回一个布尔值，指示是否具有该权限。

6. `kubectl -n test auth can-i get pods --as=system:serviceaccount:test:udbs`：这个命令用于检查"test:udbs" ServiceAccount是否具有在"test"命名空间中获取pods的权限。它会返回一个布尔值，指示是否具有该权限。

这些命令的目的是创建和管理Role、RoleBinding对象，并验证ServiceAccount是否具有特定资源的特定权限。通过这些命令，可以实现对ServiceAccount的权限分配和权限验证。
1
2
3
4
5
6
7
8
9
10
11
12
13

---

总结

以上是今天要讲的内容，学到了访问控制，包括 ServiceAccount，Role和ClusterRole。