k8s record 20240705

k8s 安全管理

request 是1g，你得不到要求，我就不创建了，这就是准入控制二次校验

SA就是serviceAccount。 内部是SA和 token, 外部用户进来就是 .kube/config文件
namespace下的是role，整个集群是 ClusterRole. 动作就是Binding
limitRanger就是满足要求就让你创建，不满足要求就不让你创建，ResourceQuota资源配额。PodSecurityPolicy让我们超越pod的限制，进行一些宿主机级别的操作

SA 服务账号

集群内部使用 namespace级别的
创建ServiceAccount后会自带 Tokens

不是的，“可以访问被允许的 ConfigMap 资源”并不意味着可以访问所有的 ConfigMap 资源，而是指可以访问特定的、被授予权限的 ConfigMap 资源。这取决于你在 Role 和 RoleBinding 中配置的权限范围。

让我们更具体地看一下如何通过 Role 和 RoleBinding 来控制对 ConfigMap 的访问权限。

细粒度控制 ConfigMap 访问权限

在 Role 中，你可以指定允许访问的资源、操作和命名空间。例如：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: read-configmaps
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "list"]
  resourceNames: ["my-configmap"]  # 仅允许访问名为 "my-configmap" 的 ConfigMap

上面的配置指定了一个 Role，该 Role 只允许读取名为 my-configmap 的 ConfigMap。

示例

创建一个 ServiceAccount：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-service-account
  namespace: default

1. 创建 Role

创建一个只允许访问特定 ConfigMap 的 Role：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: read-specific-configmap
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "list"]
  resourceNames: ["my-configmap"]  # 仅允许访问名为 "my-configmap" 的 ConfigMap

保存为 role-specific-configmap.yaml，然后应用：

kubectl apply -f role-specific-configmap.yaml

2. 创建 RoleBinding

将这个 Role 绑定到 ServiceAccount：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-specific-configmap-binding
  namespace: default
subjects:
- kind: ServiceAccount
  name: my-service-account
  namespace: default
roleRef:
  kind: Role
  name: read-specific-configmap
  apiGroup: rbac.authorization.k8s.io

保存为 rolebinding-specific-configmap.yaml，然后应用：

kubectl apply -f rolebinding-specific-configmap.yaml

关联 ServiceAccount 和 Pod

将 ServiceAccount 关联到 Pod：

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  namespace: default
spec:
  serviceAccountName: my-service-account
  containers:
  - name: my-container
    image: my-image

保存为 pod.yaml，然后应用：

kubectl apply -f pod.yaml

总结

通过上述步骤，你的 my-pod 将使用 my-service-account，并且只能读取名为 my-configmap 的 ConfigMap，而不能访问其他的 ConfigMap。这就是细粒度访问控制的意义所在。

• Role：定义了可以访问的资源类型、操作以及具体的资源名称。
• RoleBinding：将 Role 绑定到特定的 ServiceAccount。
• ServiceAccount：为 Pod 提供身份和权限。

通过这种方式，你可以非常精细地控制每个 Pod 的权限，确保它们只能访问必要的资源。

UA 用户账号

k8s自己相关证书存放的目录 /etc/k8s/pki/

在linux操作系统中，我们有且仅有一个root账户，还能有若干个普通账户；root账户的权限最大，普通账户如果需要某些特殊的权限的话，是需要我们root账户去给它授权的。而这些给我们提供使用的，在k8s的具体体现，那就是user account
在企业中，并不是只有我们一个人使用k8s集群，还有很多的研发人员都是需要使用集群的；这时我们需要给他们创建一些账号，但是这些账号权限又不能太大，以防误删资源，这个时候我们就能使用user account了

user account如何和服务器的普通用户绑定？或者说怎么能让用户小明使用k8s的时候只能使用jane

将服务器的普通用户（例如“小明”）与 Kubernetes 中的 User Account（如“jane”）绑定通常涉及以下几个步骤：

1. 创建 User Account（在 Kubernetes 中）：定义并配置 Kubernetes 中的 User Account（例如“jane”）。
2. 创建和分发认证凭证：为 User Account 创建 X.509 证书或 Bearer Token，并将其分发给小明。
3. 配置 kubeconfig 文件：将认证凭证和集群信息配置到小明的 kubeconfig 文件中。
4. 权限控制：使用 RBAC 将合适的权限分配给 User Account。

以下是详细步骤：

1. 创建和分发认证凭证

使用 X.509 证书

1. 创建私钥和证书签名请求（CSR）：

   openssl genrsa -out jane.key 2048
   openssl req -new -key jane.key -out jane.csr -subj "/CN=jane/O=developers"
   

2. 签署证书（假设使用 Kubernetes 的 CA 证书进行签名）：

   openssl x509 -req -in jane.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out jane.crt -days 365
   

3. 分发证书和私钥：

   将 jane.crt 和 jane.key 分发给小明。

2. 配置 kubeconfig 文件

1. 为小明配置 kubeconfig 文件：

   创建或编辑小明的 kubeconfig 文件（通常位于 ~/.kube/config），添加以下内容：

   apiVersion: v1
   kind: Config
   clusters:
   - cluster:
       certificate-authority: /etc/kubernetes/pki/ca.crt
       server: https://<kubernetes-api-server>
     name: kubernetes
   contexts:
   - context:
       cluster: kubernetes
       user: jane
     name: jane-context
   current-context: jane-context
   users:
   - name: jane
     user:
       client-certificate: /path/to/jane.crt
       client-key: /path/to/jane.key
   

   确保 certificate-authority、client-certificate 和 client-key 的路径正确。

2. 将 kubeconfig 文件复制到小明的主目录：

   cp /path/to/kubeconfig /home/xiaoming/.kube/config
   chown xiaoming:xiaoming /home/xiaoming/.kube/config
   

3. 配置 RBAC

1. 创建 Role：

   定义一个 Role，例如允许读取 Pods：

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     namespace: default
     name: pod-reader
   rules:
   - apiGroups: [""]
     resources: ["pods"]
     verbs: ["get", "list"]
   

   保存为 role.yaml 并应用：

   kubectl apply -f role.yaml
   

2. 创建 RoleBinding：

   将 Role 绑定到 User Account：

   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: read-pods
     namespace: default
   subjects:
   - kind: User
     name: "jane"  # 这是 User Account 的名字
     apiGroup: rbac.authorization.k8s.io
   roleRef:
     kind: Role
     name: pod-reader
     apiGroup: rbac.authorization.k8s.io
   

   保存为 rolebinding.yaml 并应用：

   kubectl apply -f rolebinding.yaml
   

总结

通过这些步骤，您可以将服务器上的普通用户（如小明）与 Kubernetes 中的 User Account（如“jane”）绑定。具体步骤包括：

1. 为 User Account 创建认证凭证（如 X.509 证书）。
2. 将认证凭证配置到小明的 kubeconfig 文件中。
3. 使用 RBAC 为 User Account 分配适当的权限。

这样，小明在使用 kubectl 时就会以 User Account “jane”的身份进行操作，并且只能执行被授予的权限。

config

指定的用户，特定的集群


在 Kubernetes 中，xiaoming（或小明）的配置文件（kubeconfig 文件）、ServiceAccount（服务账号）和 User Account（用户账号）是 Kubernetes 认证和授权机制中的不同概念，它们各自扮演着不同的角色，但在一定情况下会有交集或者可以相互关联。

1. kubeconfig 文件

kubeconfig 文件是用来配置 Kubernetes 客户端工具（如 kubectl）如何连接到 Kubernetes 集群的文件。它包含了以下主要内容：

• Clusters：定义可以访问的 Kubernetes 集群的位置和相关信息。
• Users：定义用户如何进行身份验证（如使用用户名密码、客户端证书等）。
• Contexts：定义了一个特定集群、用户和命名空间的组合，以及当前使用的上下文。

kubeconfig 文件中的用户（User）部分配置了用于身份验证的凭据，如证书、令牌或用户名密码。通过设置正确的上下文（Context），可以使 kubectl 在执行命令时使用正确的集群和用户凭据。

2. ServiceAccount（服务账号）

ServiceAccount 是 Kubernetes 中一种资源对象，用于授权 Pod 中运行的应用程序访问 Kubernetes API。每个 Pod 都会关联一个 ServiceAccount，默认情况下是 default ServiceAccount。ServiceAccount 提供了身份验证信息，允许 Pod 在集群内执行特定操作而无需直接使用集群用户的凭据。

ServiceAccount 主要用于控制 Pod 访问 Kubernetes API 的权限，例如，控制 Pod 是否具有创建其他资源的权限或访问特定 ConfigMap 或 Secret 的权限。

3. User Account（用户账号）

User Account 是指 Kubernetes 中配置的用户身份。这些用户通常用于管理 Kubernetes 集群，而不是在 Pod 内运行的应用程序。User Account 通常在 kubeconfig 文件中配置，用于管理员或其他有权限的用户访问 Kubernetes 集群。

User Account 可以通过不同的认证机制进行验证，如用户名密码、客户端证书等。它们与 ServiceAccount 不同，后者是用于授权 Pod 内的应用程序访问 Kubernetes API 的。

理解 kubectl config set-credentials 的关键在于知道它如何在 kubeconfig 文件中设置或更新用户的认证信息。让我通过一个具体的示例来详细解释这个命令的用途和使用方法。

具体示例

假设你有一个新的 Kubernetes 用户 xiaoming，你希望为他配置访问 Kubernetes 集群的认证信息。

1. 生成客户端证书和密钥

假设已经生成好了以下文件：

• xiaoming.crt (客户端证书)
• xiaoming.key (客户端密钥)

2. 使用 kubectl config set-credentials 命令配置认证信息

我们将在 kubeconfig 文件中添加用户 xiaoming 的认证信息。

kubectl config set-credentials xiaoming --client-certificate=/path/to/xiaoming.crt --client-key=/path/to/xiaoming.key

这个命令的意思是：

• xiaoming：用户名称
• –client-certificate：指向客户端证书的文件路径
• –client-key：指向客户端密钥的文件路径

运行这个命令后，kubeconfig 文件会更新或添加如下内容：

users:
- name: xiaoming
  user:
    client-certificate: /path/to/xiaoming.crt
    client-key: /path/to/xiaoming.key

3. 配置集群和上下文

假设集群名称为 my-cluster，API 服务器的地址为 https://api-server.example.com，CA 证书文件路径为 /path/to/ca.crt。

kubectl config set-cluster my-cluster --server=https://api-server.example.com --certificate-authority=/path/to/ca.crt

这条命令会在 kubeconfig 文件中添加或更新集群信息：

clusters:
- cluster:
    certificate-authority: /path/to/ca.crt
    server: https://api-server.example.com
  name: my-cluster

4. 创建上下文并切换到新上下文

上下文关联了集群和用户信息，便于 kubectl 使用。

kubectl config set-context xiaoming-context --cluster=my-cluster --user=xiaoming
kubectl config use-context xiaoming-context

这两条命令会在 kubeconfig 文件中添加或更新上下文信息，并设置当前上下文：

contexts:
- context:
    cluster: my-cluster
    user: xiaoming
  name: xiaoming-context
current-context: xiaoming-context

总结

通过以上步骤，用户 xiaoming 就可以使用 kubectl 访问 Kubernetes 集群了。以下是整个 kubeconfig 文件的内容示例：

apiVersion: v1
kind: Config
clusters:
- cluster:
    certificate-authority: /path/to/ca.crt
    server: https://api-server.example.com
  name: my-cluster
users:
- name: xiaoming
  user:
    client-certificate: /path/to/xiaoming.crt
    client-key: /path/to/xiaoming.key
contexts:
- context:
    cluster: my-cluster
    user: xiaoming
  name: xiaoming-context
current-context: xiaoming-context

主要步骤总结

1. 生成客户端证书和密钥：为用户生成认证凭证。
2. 配置认证信息：使用 kubectl config set-credentials 命令将用户的认证信息添加到 kubeconfig 文件中。
3. 配置集群信息：使用 kubectl config set-cluster 命令添加集群信息。
4. 配置上下文并切换：使用 kubectl config set-context 和 kubectl config use-context 命令添加上下文并设置当前使用的上下文。

通过上述步骤创建的用户 xiaoming，在 Kubernetes 中具有根据其配置的权限和角色所允许的能力。这取决于以下几个因素：

1. 配置的 RBAC 角色和权限：

   • 如果给 xiaoming 分配了适当的 Role 或 ClusterRole，并且这些 Role 具有对某些资源（如 Pods、Deployments 等）的特定操作权限（如创建、获取、删除等），那么 xiaoming 就能执行这些操作。

2. 命名空间限制：

   • 如果 xiaoming 被限制在特定的命名空间中，那么他只能在这个命名空间内执行操作，而不能跨命名空间操作资源。

3. kubectl 命令使用权限：

   • xiaoming 可以使用 kubectl 命令执行他具有权限的任何操作。例如，他可以列出 Pods、获取服务的详细信息、创建或删除资源等，取决于他被授予的具体权限。

优先级

.kube/config 小于 export KUBECONFIG=/tmp/superopesmsb.conf< admin.conf

用户 bind 角色。这个用户就有了这个角色操作相关资源的权限 — 这就是基于角色的权限访问控制 RBAC

1. namespace：比如张三来了，赋予市场部经理的角色，那么他只负责市场部，role只赋予一个namespace的范围
2. cluster: 张三提升为 总裁。比如ClusterRole, 多个命名空间，集群级别，是 ClusterRolebinding，不在是 Rolebinding
3. 混合级别：张三虽然提升为总裁，但对能力不能确定，有个观察期，期间只负责财务部一个namespace. 虽然角色是ClusterRole，但是用的是Rolebinding, 不是 ClusterRolebinding。

Role就是 xx资源的 xx 权限
apiGroups可以是 α版本的，http,https等等。”“ 代表所有资源版本
主要是apiGroups和 resources，使用这两个列表

在 Kubernetes 的 RBAC（角色基于访问控制）系统中，apiGroups 列表用于指定资源所属的 API 组。Kubernetes 的 API 资源分布在不同的 API 组中，每个 API 组包含一组相关的资源和操作。通过在 Role 或 ClusterRole 中指定 apiGroups，可以控制对特定 API 组中资源的访问权限。

常见的 API 组及其意义

以下是一些常见的 API 组及其含义：

1. Core API Group ("")

   • 空字符串表示核心 API 组。
   • 包含 Kubernetes 的核心资源，如 Pods、Services、ConfigMaps、Secrets、Namespaces、Nodes 等。
   • 示例：

     apiGroups: [""]
     resources: ["pods", "services", "configmaps", "secrets"]
     

2. apps

   • 包含与应用管理相关的资源。
   • 主要资源包括 Deployments、StatefulSets、DaemonSets、ReplicaSets 等。
   • 示例：

     apiGroups: ["apps"]
     resources: ["deployments", "statefulsets", "daemonsets", "replicasets"]
     

3. batch

   • 包含与批处理作业相关的资源。
   • 主要资源包括 Jobs 和 CronJobs。
   • 示例：

     apiGroups: ["batch"]
     resources: ["jobs", "cronjobs"]
     

4. extensions

   • 包含一些早期版本的资源，现在大多数资源已移到其他 API 组。
   • 示例：

     apiGroups: ["extensions"]
     resources: ["deployments", "daemonsets", "replicasets"]
     

5. rbac.authorization.k8s.io

   • 包含与 RBAC 相关的资源。
   • 主要资源包括 Roles、RoleBindings、ClusterRoles、ClusterRoleBindings。
   • 示例：

     apiGroups: ["rbac.authorization.k8s.io"]
     resources: ["roles", "rolebindings", "clusterroles", "clusterrolebindings"]
     

6. policy

   • 包含与策略管理相关的资源。
   • 主要资源包括 PodSecurityPolicies。
   • 示例：

     apiGroups: ["policy"]
     resources: ["podsecuritypolicies"]
     

7. networking.k8s.io

   • 包含与网络相关的资源。
   • 主要资源包括 NetworkPolicies、Ingresses。
   • 示例：

     apiGroups: ["networking.k8s.io"]
     resources: ["networkpolicies", "ingresses"]
     

8. storage.k8s.io

   • 包含与存储管理相关的资源。
   • 主要资源包括 StorageClasses、VolumeAttachments。
   • 示例：

     apiGroups: ["storage.k8s.io"]
     resources: ["storageclasses", "volumeattachments"]
     

9. autoscaling

   • 包含与自动扩缩相关的资源。
   • 主要资源包括 HorizontalPodAutoscalers。
   • 示例：

     apiGroups: ["autoscaling"]
     resources: ["horizontalpodautoscalers"]
     

10. apiextensions.k8s.io

    • 包含与 API 扩展相关的资源。
    • 主要资源包括 CustomResourceDefinitions。
    • 示例：

      apiGroups: ["apiextensions.k8s.io"]
      resources: ["customresourcedefinitions"]
      

自定义 API 组

如果你在 Kubernetes 中使用自定义资源定义（CRD），可以定义自己的 API 组。这些 API 组通常是你自己定义的，与你的应用或业务逻辑相关。

例如，假设你创建了一个名为 example.com 的自定义 API 组，并在其中定义了一个名为 MyResource 的资源：

apiGroups: ["example.com"]
resources: ["myresources"]

kubeconfig里设置的用户，rolebinding 到一个角色。Role 和 RoleBinding 的 metadata.namespace 字段共同决定了权限在哪个命名空间内有效。binding后这个用户在其他命名空间就没了操作权限


SA的认证模式是 token, UA的认证模式是 证书+密钥，也就是那个config
RoleBinding 将 Role 绑定到一个或多个 ServiceAccount 或 UserAccount 上，使这些账户获得该 Role 中定义的权限。

ClusterRole cluster-admin
cluster-admin 是 Kubernetes 中预定义的一个 ClusterRole，它包含了所有的权限，可以对集群中的所有资源进行任意操作。绑定到 cluster-admin 角色的账户将获得集群管理员的全部权限。
如果一个 ServiceAccount 被绑定到 ClusterRole cluster-admin 通过 ClusterRoleBinding，那么这个 ServiceAccount 将获得集群中的所有权限

kubeConfig

kubeconfig 文件是 Kubernetes 客户端（如 kubectl）用来访问 Kubernetes 集群的配置文件。它定义了如何连接到集群、如何认证用户以及如何在多个集群和用户之间切换。具体来说，kubeconfig 文件主要包括以下几个部分：

1. 定义集群（Clusters）：描述如何连接到 Kubernetes API 服务器。
2. 定义用户（Users）：描述用于连接集群的用户凭证。
3. 定义上下文（Contexts）：将集群、用户和命名空间组合在一起，方便切换。
4. 应用上下文（Current Context）：指定当前使用的上下文。

示例 kubeconfig 文件

apiVersion: v1
kind: Config
clusters:
- cluster:
    server: https://kubernetes.example.com
    certificate-authority: /path/to/ca.crt
  name: my-cluster
users:
- name: my-user
  user:
    client-certificate: /path/to/client.crt
    client-key: /path/to/client.key
contexts:
- context:
    cluster: my-cluster
    user: my-user
    namespace: my-namespace
  name: my-context
current-context: my-context

解释

定义集群（Clusters）

clusters:
- cluster:
    server: https://kubernetes.example.com
    certificate-authority: /path/to/ca.crt
  name: my-cluster

• clusters：包含一个或多个集群配置。
• name：集群的名称，用于在上下文中引用。
• server：API 服务器的地址。
• certificate-authority：用于验证 API 服务器的证书。

定义用户（Users）

users:
- name: my-user
  user:
    client-certificate: /path/to/client.crt
    client-key: /path/to/client.key

• users：包含一个或多个用户配置。
• name：用户的名称，用于在上下文中引用。
• client-certificate 和 client-key：用于客户端认证的证书和密钥。

定义上下文（Contexts）

contexts:
- context:
    cluster: my-cluster
    user: my-user
    namespace: my-namespace
  name: my-context

• contexts：包含一个或多个上下文配置。
• name：上下文的名称，可以任意指定。
• cluster：引用定义的集群名称。
• user：引用定义的用户名。
• namespace（可选）：默认的命名空间，如果未指定，则使用默认命名空间。

应用上下文（Current Context）

current-context: my-context

• current-context：指定当前使用的上下文名称，决定了 kubectl 命令的默认集群、用户和命名空间。

使用示例

假设你有一个 kubeconfig 文件，名为 config.yaml。你可以使用以下命令来管理和使用 kubeconfig 文件中的配置：

1. 查看当前上下文：

   kubectl config current-context
   

2. 切换上下文：

   kubectl config use-context my-context
   

3. 查看可用的上下文：

   kubectl config get-contexts
   

4. 指定使用特定的 kubeconfig 文件：

   kubectl --kubeconfig=config.yaml get pods
   

通过定义集群、用户和上下文，并应用上下文，kubeconfig 文件使得 Kubernetes 客户端能够灵活地在不同的集群和用户之间切换，并确保连接的安全性和准确性。