Kubernetes从零到夺目（15-安全）

 
目次
一、Kubernetes API访问控制
1.传输安全(Transport Security)
2.认证(Authentication)
2.1 认证方式
2.2 ServiceAccount和平常用户的区别
2.3 ServiceAccount管理方式
自动ServiceAccount示例
手动ServiceAccount示例
 3.鉴权 (Authorization)
3.1鉴权方式
3.2 RBAC
4.准入控制 (Admission Control)
PodSecurity
安全级别
 安全实行
设置示例
二、审计 (Auditing)
审计架构
审计战略（Audit Policy）
审计级别
审计战略文件示例
审计日志的存储（Audit Sink）
审计变乱结构
三、Secret
四、网络战略（NetworkPolicy)
网络战略的作用
网络战略的工作原理
网络战略示例

---

       Kubernetes（K8s）是一个强盛的容器编排平台，安全性至关告急。Kubernetes的安全机制可以分为多个条理，包罗集群层、网络层、应用层等。以下是Kubernetes中重要的安全机制：Kubernetes API访问控制、Secret、网络战略（NetworkPolicy) 、审计日志等等。
一、Kubernetes API访问控制

        Kubernetes API访问控制是一组机制，确保只有颠末授权的用户或服务可以访问和操纵集群资源。它涵盖了多个层面，包罗传输安全、认证、鉴权、准入控制和审计。以下是这些概念的详细先容。

1.传输安全(Transport Security)

Kubernetes默认使用HTTPS来确保API通讯的安全性，防止数据在传输过程中被盗取或窜改。API服务器会使用TLS（传输层安全协议）对哀求举行加密：
客户端与服务器间通讯加密：通过使用TLS证书来验证服务器和客户端的身份，从而加密通讯。
Kubernetes API server的证书管理：必要为Kubernetes集群中的API服务器设置准确的证书（包罗根证书和客户端证书）。
掩护内部组件的通讯：比如etcd的通讯必要加密，并使用恰当的证书。
2.认证(Authentication)

2.1 认证方式

        全部Kubernetes集群都有两类用户：由Kubernetes管理的服务账户（ServiceAccount）、平常用户。全部API哀求都必要颠末身份认证，以确保哀求来自正当用户或服务，并授予恰当的权限。Kubernetes支持多种认证方式，此中比力常见的是基于令牌的身份验证、x509证书、OpenID Connect（OIDC）、服务账户（ServiceAccount）等。
x509证书：用户通过x509证书与API服务器举行通讯。这种方式通常用于Kubernetes管理员、集群节点和集群内的一些服务。比方：客户端使用带有效户身份的证书，通过kubectl下令访问API服务器。
Bearer Token：Kubernetes使用令牌（Token）举行身份验证，客户端可以通过将Bearer Token附加到HTTP哀求中举行身份验证。
OIDC(OpenID Connect)：通过外部身份提供者（如Google、AWS、Keycloak等）验证用户身份。OIDC是一种基于OAuth2.0协议的身份验证协议，恰当于与外部认证服务集成。
服务账户（ServiceAccount）：服务账户用于集群内的应用步调或Pod来访问API服务器，通常与RBAC（基于脚色的访问控制）联合使用。
        可以指定多个认证模块，在这种情况下，服务器依次实验每个验证模块，直到此中一个乐成。
2.2 ServiceAccount和平常用户的区别

        平常用户通常是指通过kubeconfig文件、证书或OIDC等方式认证的用户，通常是Kubernetes集群的管理员或开辟者；Kubernetes不会直接在集群中创建或管理平常用户。
        平常用户使用场景：平常用户用于手动管理集群资源（比方 kubectl 下令行工具）或访问Kubernetes API。
        ServiceAccount是Kubernetes中的一种特殊范例的账户，用于赋予Pod在集群中运行时的身份。它重要用于集群内的自动化服务，而不是手动用户操纵。
        ServiceAccount使用场景：ServiceAccount常用于必要与API服务器交互的应用步调，或用于Pod自动管理集群资源。比方CI/CD工具、监控工具、控制器等。
2.3 ServiceAccount管理方式

        每个ServiceAccount都与一个JSON Web Token (JWT) 关联，该令牌存储在Pod的文件体系中，位于 /var/run/secrets/kubernetes.io/serviceaccount/token路径下。Pod启动后，会使用这个令牌与Kubernetes API服务器举行通讯，API服务器根据该令牌举行身份验证。ServiceAccount通常与RBAC联合，授予Pod访问某些API资源的权限。
        ServiceAccount可以通过自动或手动方式使用。默认情况下，每个定名空间Namespace都有一个默认的ServiceAccount，Pod启动时会自动关联这个ServiceAccount。假如必要更高的权限或特殊用途，我们也可以手动创建并指定ServiceAccount。
自动ServiceAccount示例

        创建及查察Pod：
   #创建Pod
  kubectl run my-pod --image=nginx
  #查察Pod的ServiceAccount
  kubectl get pod my-pod -o yaml
          在输出中，会看到以下部分，表现该Pod使用了default ServiceAccount： 
   serviceAccount: default
serviceAccountName: default
          查察ServiceAccount令牌:
   kubectl exec -it my-pod -- cat /var/run/secrets/kubernetes.io/serviceaccount/token
  手动ServiceAccount示例

        创建ServiceAccount：
   #手动创建一个新的ServiceAccount
  kubectl create serviceaccount my-service-account
#查察ServiceAccount的详细信息
  kubectl get serviceaccount my-service-account -o yaml
           创建Pod并绑定自界说的ServiceAccount：

1. apiVersion: v1
2. kind: Pod
3. metadata:
4.   name: my-pod-with-sa
5. spec:
6.   serviceAccountName: my-service-account  # 指定使用的ServiceAccount
7.   containers:
8.   - name: my-container
9.     image: nginx

复制代码

        验证Pod是否绑定了自界说ServiceAccount：
   #创建Pod
  kubectl apply -f pod-with-sa.yaml
#查察该 Pod 的详细信息
  kubectl get pod my-pod-with-sa -o yaml
          输出中会表现：
   serviceAccount: my-service-account
serviceAccountName: my-service-account 
          为ServiceAccount设置权限（可选）:
   #授予my-service-account读取Pod信息的权限。
  kubectl create role my-role --verb=get,list,watch --resource=pods
kubectl create rolebinding my-role-binding --role=my-role --serviceaccount=default:my-service-account
          ServiceAccount 默认没有太多权限，可以使用Role和RoleBinding为它设置权限。
        关于权限在鉴权 (Authorization)部分阐明。 
 3.鉴权 (Authorization)

3.1鉴权方式

        在认证之后，Kubernetes会决定认证通过的用户是否有权限实行特定操纵。Kubernetes使用多种授权方式来控制API哀求的访问权限。
RBAC (基于脚色的访问控制)：基于预界说的脚色来授予用户或组的权限，通过Role和ClusterRole联合RoleBinding和ClusterRoleBinding来实行访问控制。
ABAC (基于属性的访问控制)：通过指定战略文件，根据哀求的属性（如用户名、资源范例、动作）决定是否授权。
Webhook模式：将鉴权哀求转发到外部服务处理处罚，恰当实现自界说的访问控制逻辑。
3.2 RBAC

        RBAC（Role-Based Access Control，基于脚色的访问控制）是Kubernetes中的一种访问控制机制，用于界说用户或服务账号对 Kubernetes 资源的访问权限。通过 RBAC，集群管理员可以根据脚色分配权限，并通过绑定这些脚色给用户、组或ServiceAccount来控制访问权限。
        RBAC 重要由四个核心组件构成：

• Role：界说某个特定Namespace下的权限。它包罗了对资源（比方Pods、Services等）的操纵规则（如get、create、delete等）。
  
• ClusterRole：界说集群范围的权限，可以在全部Namespace中使用，或直策应用于集群级资源（如节点、PersistentVolumes等）。
  
• RoleBinding：将Role绑定到用户、组或ServiceAccount，使其在指定的Namespace中拥有相应的权限。
  
• ClusterRoleBinding：将ClusterRole绑定到用户、组或ServiceAccount，使其在整个集群中拥有相应的权限。
  

        Role & RoleBinding示例：

1. apiVersion: rbac.authorization.k8s.io/v1
2. kind: Role
3. metadata:
4.   namespace: default  #作用范围是default命名空间
5.   name: pod-reader
6. rules:
7. - apiGroups: [""]  #空字符串表示核心API组
8.   resources: ["pods"]
9.   verbs: ["get", "list", "watch"]  #授予的操作权限

复制代码

1. apiVersion: rbac.authorization.k8s.io/v1
2. kind: RoleBinding
3. metadata:
4.   name: read-pods
5.   namespace: default
6. subjects:  #绑定的用户或服务账户
7. - kind: User  #可以是User、Group或ServiceAccount
8.   name: "example-user"  #用户名
9.   apiGroup: rbac.authorization.k8s.io
10. roleRef:
11.   kind: Role  #绑定的角色类型
12.   name: pod-reader  #绑定的角色名称
13.   apiGroup: rbac.authorization.k8s.io

复制代码

        example-user如今拥有default定名空间中读取pods资源的权限。 
         ClusterRole & ClusterRoleBinding示例：

1. apiVersion: rbac.authorization.k8s.io/v1
2. kind: ClusterRole
3. metadata:
4.   name: cluster-pod-reader
5. rules:
6. - apiGroups: [""]  # 核心API组
7.   resources: ["pods"]
8.   verbs: ["get", "list", "watch"]

复制代码

1. apiVersion: rbac.authorization.k8s.io/v1
2. kind: ClusterRoleBinding
3. metadata:
4.   name: read-pods-clusterwide
5. subjects:  #绑定的用户或服务账户
6. - kind: User
7.   name: "example-user"  #用户名
8.   apiGroup: rbac.authorization.k8s.io
9. roleRef:
10.   kind: ClusterRole  #绑定ClusterRole
11.   name: cluster-pod-reader  #绑定的角色名称
12.   apiGroup: rbac.authorization.k8s.io

复制代码

        ci-service-account如今可以读取集群中全部定名空间的Pod信息。
4.准入控制 (Admission Control)

        准入控制是对颠末认证和授权的API哀求举行进一步的查抄和修改的一个步调。在哀求进入Kubernetes API Server之前，准入控制器可以克制哀求或修改对象。保举使用的准入控制器默认情况下都处于启用状态。可以使用--enable-admission-plugins来启用默认设置以外的其他准入控制器。
        常见的内置准入控制器：比方NamespaceLifecycle、LimitRanger、PodSecurity、RuntimeClass等，用于特定的访问和资源管理。以下先容PodSecurity概念：
PodSecurity

         Pod 安全性尺度（Pod Security Standards，PSS）是Kubernetes提供的一套安全尺度，用于界说和管理Pod 的安全战略。通过使用Pod安全性尺度，Kubernetes集群管理员可以控制和限定 Pod在运行时的举动，从而进步集群的团体安全性。这套尺度是通过Kubernetes的内置准入控制器PodSecurity来实现的。
        默认情况下，Kubernetes不启用PodSecurity，因此没有默认的安全级别和模式。假如启用PodSecurity准入控制器，默认的安全级别和模式必要手动设置。
安全级别

        Pod 安全性尺度重要界说了三个安全级别（或模式）：

• 特权级别（Privileged）
  
  
  
  • 用途：最宽松的安全级别，允许Pod以完全特权运行。实用于那些必要完全控制底层主机的Pod，比方必要实行主机级别操纵的体系组件或Pod。
    
  • 特点：
    
    
    
    • 允许使用特权模式、HostPath挂载、特权容器、HostNetwork等功能。
      
    • 险些没有安全束缚，风险较高。
      
    
    
  
  
• 基线级别（Baseline）
  
  
  
  • 用途：旨在允许大多数应用步调正常运行，同时施加根本的安全限定。恰当一样平常的应用步调。
    
  • 特点：
    
    
    
    • 拒绝特权模式和特权容器。
      
    • 限定HostPath挂载，防止容器访问主机的敏感文件。
      
    • 限定某些Linux特性，如CAP_SYS_ADMIN等高危特权。
      
    • 克制使用HostNetwork和HostPID。
      
    
    
  
  
• 受限级别（Restricted）
  
  
  
  • 用途：最严酷的安全级别，施加了全部可用的最佳安全实践。实用于高度敏感的应用步调，必要严酷限定Pod的举动。
    
  • 特点：
    
    
    
    • 克制统统特权操纵，包罗HostPath挂载、特权容器、HostNetwork、HostPID、HostIPC等。
      
    • 逼迫限定容器的用户权限（如不能以root用户身份运行容器）。
      
    • 逼迫限定进程和文件体系的权限，最大限度淘汰攻击面。
      
    
    
  
  

 安全实行

          Pod 安全性尺度的实行分为以下几种操纵模式：

• Enforce（实行）：逼迫实行指定的安全战略，假如Pod不符合要求，则克制其创建或更新。
  
• Audit（审计）：纪录违背安全战略的操纵，但不克制Pod创建或更新。
  
• Warn（告诫）：向用户发出告诫，关照其违背了安全战略，但不克制Pod创建或更新。
  

        这些模式允许管理员以递进方式加强安全控制，渐渐引导开辟职员顺应更严酷的安全尺度。
设置示例

1. apiVersion: v1
2. kind: Namespace
3. metadata:
4.   name: restricted-namespace
5.   labels:
6.     pod-security.kubernetes.io/enforce: "restricted"  #强制执行受限级别
7.     pod-security.kubernetes.io/audit: "baseline"      #审计基线级别
8.     pod-security.kubernetes.io/warn: "baseline"       #警告基线级别

复制代码

        在这个示例中，restricted-namespace定名空间中，逼迫实行受限级别的Pod安全战略，并在审计和告诫模式下评估基线级别的战略。

1. apiVersion: v1
2. kind: Namespace
3. metadata:
4.   name: baseline-namespace
5.   labels:
6.     pod-security.kubernetes.io/enforce: "baseline"  #强制执行基线级别

复制代码

        在这个示例中，baseline-namespace定名空间中，全部创建的Pod必须符合基线级别的安全尺度，否则创建或更新哀求将被拒绝。 
二、审计 (Auditing)

         Kubernetes 审计日志会纪录API服务器处理处罚的每一个HTTP哀求，它包罗从哀求的吸收到终极的处理处罚效果（允许或拒绝），以及返回的相应。审计的变乱按照发生的序次纪录下来，管理员可以根据这些日志相识集群的操纵情况。
        Kubernetes 默认没有开启审计，必要在kube-apiserver的设置文件中启用审计功能，并手动设置审计战略文件。API 服务器不默认天生审计日志，也没有预设的审计级别。
审计架构

审计体系由三个重要组件构成：

• Audit Policy：界说审计变乱的纪录规则，如纪录哪些操纵、哪些用户的举动等。
  
• Audit Sink：审计日志的存储位置，可以是文件、尺度输出，或通过HTTP Webhook发送到外部服务。
  
• Audit Event：每个 API 哀求会被纪录为一个审计变乱，包罗详细的上下文信息。
  

审计战略（Audit Policy）

        审计战略通过一个战略文件来界说，战略文件控制什么样的API哀求会被纪录，以及纪录的详细水平。
审计级别

        每个哀求可以按差别的审计级别纪录：

• None：不纪录任何内容。
  
• Metadata：仅纪录哀求的元数据（如用户、操纵、时间等），不纪录哀求和相应的内容。
  
• Request：纪录哀求的元数据以及哀求体，但不纪录相应体。
  
• RequestResponse：纪录哀求的元数据、哀求体和相应体，包罗了全部详细信息。
  

审计战略文件示例

        一个典范的审计战略文件会界说差别资源、差别用户和操纵的纪录级别。下面是一个示例战略文件：
 

1. apiVersion: audit.k8s.io/v1
2. kind: Policy
3. rules:
4. - level: RequestResponse  # 对于所有的pod操作，记录请求和响应
5.   resources:
6.   - group: ""
7.     resources: ["pods"]
8. - level: Metadata  #对于所有的secrets操作，记录元数据
9.   resources:
10.   - group: ""
11.     resources: ["secrets"]
12. - level: None  #忽略对serviceaccounts的请求
13.   resources:
14.   - group: ""
15.     resources: ["serviceaccounts"]
16. - level: Request  #记录所有的请求操作和元数据
17.   users: ["system:serviceaccount:kube-system:default"]
18.   verbs: ["create", "update", "patch"]
19. - level: Metadata  #默认记录所有其他请求的元数据
20.   omitStages:
21.   - "RequestReceived"

复制代码

        这个战略文件的规则阐明如下：

• 对于全部的Pod操纵，纪录详细的哀求和相应。
  
• 对于 Secret 操纵，仅纪录元数据（比方操纵的时间、用户）。
  
• 忽略ServiceAccount的全部操纵。
  
• 对特定的服务账户的create、update、patch哀求，纪录哀求的详细信息。
  
• 对全部其他哀求，默认纪录元数据。
  

审计日志的存储（Audit Sink）

        Kubernetes 支持多种审计日志的输出方式，通常包罗：

• 文件输出：将审计日志写入文件。
  
• Webhook 输出：通过HTTP POST哀求将审计日志发送到外部服务。
  

        文件输出是一种常见的方式，API服务器可以将审计日志写入到指定文件。 启动kube-apiserver时，可以通过以下参数设置文件输出：、
   kube-apiserver \
  --audit-policy-file=/etc/kubernetes/audit-policy.yaml \
  --audit-log-path=/var/log/kubernetes/audit.log \
  --audit-log-maxage=30 \
  --audit-log-maxbackup=10 \
  --audit-log-maxsize=100
  

• --audit-policy-file：指定审计战略文件路径。
  
• --audit-log-path：审计日志文件的存储路径。
  
• --audit-log-maxage：日志文件生存的最大天数。
  
• --audit-log-maxbackup：生存的旧审计日志文件的最大数量。
  
• --audit-log-maxsize：每个日志文件的最大巨细（以 MB 为单元）。
  

审计变乱结构

         审计日志中的每个变乱都包罗丰富的上下文信息，在下面的输出示例中，requestObject和 responseObject分别纪录了哀求和相应的详细内容：

1. {
2.   "kind": "Event",
3.   "apiVersion": "audit.k8s.io/v1",
4.   "level": "RequestResponse",
5.   "stage": "ResponseComplete",
6.   "requestURI": "/api/v1/namespaces/default/pods",
7.   "verb": "create",
8.   "user": {
9.     "username": "admin",
10.     "groups": ["system:masters"]
11.   },
12.   "sourceIPs": ["192.168.1.100"],
13.   "objectRef": {
14.     "resource": "pods",
15.     "namespace": "default",
16.     "name": "my-pod"
17.   },
18.   "responseStatus": {
19.     "metadata": {},
20.     "code": 201
21.   },
22.   "requestObject": {
23.     "kind": "Pod",
24.     "metadata": {
25.       "name": "my-pod"
26.     },
27.     "spec": {
28.       "containers": [
29.         {
30.           "name": "nginx",
31.           "image": "nginx:latest"
32.         }
33.       ]
34.     }
35.   },
36.   "responseObject": {
37.     "kind": "Pod",
38.     "metadata": {
39.       "name": "my-pod"
40.     },
41.     "spec": {
42.       "containers": [
43.         {
44.           "name": "nginx",
45.           "image": "nginx:latest"
46.         }
47.       ]
48.     }
49.   }
50. }

复制代码

三、Secret

        Secret API为必要保密的设置值提供根本掩护。可以回顾 Kubernetes从零到夺目（13-Configmap、Secret）
四、网络战略（NetworkPolicy)

        Kubernetes 中的网络战略（NetworkPolicy） 是一种控制Pod间流量和Pod与外部网络流量的安全机制。它允许用户界说哪些流量可以进入和离开Pod，以确保集群的安全性。
        网络战略仅会在支持网络战略的网络插件CNI（如 Calico）中收效。Kubernetes 默认的网络实现不支持网络战略。网络插件可以回顾Kubernetes从零到夺目（11-CNI网络插件）。
网络战略的作用

        NetworkPolicy是通过界说一组规则来允许或拒绝指定Pod的网络流量。这些规则可以基于：

• 定名空间：限定特定定名空间中的 Pod 间的流量。
  
• Pod 标签：限定带有特定标签的 Pod 间的流量。
  
• IP Block：限定特定的 IP 地点段的流量。
  

网络战略的工作原理

        Kubernetes 网络战略重要用来界说：

• 入口流量（Ingress）：进入Pod的流量。
  
• 出口流量（Egress）：从Pod发送出的流量。
  

没有设置网络战略时，全部Pod之间的网络流量默认是允许的，一旦界说了网络战略，只有符合规则的流量才会被允许。
网络战略的根本结构
        一个网络战略通过以下几部分界说：

• Pod选择器：选择哪些 Pod 应该应用这条战略。
  
• 战略范例：Ingress（不是Ingress、Gateway api，只是名称雷同）或Egress，指定战略是控制入口流量还是出口流量。
  
• 规则：指定允许哪些流量通过，规则可以基于Pod标签、IP 地点块、定名空间等界说。
  

网络战略示例

        下面的网络战略将克制全部流向my-pod的流量，除了带有特定标签的Pod发送的流量：

1. apiVersion: networking.k8s.io/v1
2. kind: NetworkPolicy
3. metadata:
4.   name: allow-specific-pods
5.   namespace: default
6. spec:
7.   podSelector:
8.     matchLabels:
9.       app: my-pod  #应用此策略的Pod
10.   policyTypes:
11.   - Ingress  #定义入口流量规则
12.   ingress:
13.   - from:
14.     - podSelector:
15.         matchLabels:
16.           app: allowed-app  #允许带有此标签的Pod发送流量

复制代码

        该战略允许来自特定IP地点段（如192.168.0.0/16）的流量，其他流量会被拒绝：

1. apiVersion: networking.k8s.io/v1
2. kind: NetworkPolicy
3. metadata:
4.   name: allow-from-ip-range
5.   namespace: default
6. spec:
7.   podSelector:
8.     matchLabels:
9.       app: my-pod  #应用此策略的Pod
10.   policyTypes:
11.   - Ingress
12.   ingress:
13.   - from:
14.     - ipBlock:
15.         cidr: 192.168.0.0/16  #允许的IP地址范围

复制代码

         下面的网络战略允许Pod访问外部网络（注意这里只是在战略上允许访问外部网络，底层网络能不能支持该Pod访问外部网络，必要看详细网络情况），但限定对特定定名空间内其他 Pod 的访问：

1. apiVersion: networking.k8s.io/v1
2. kind: NetworkPolicy
3. metadata:
4.   name: allow-egress
5.   namespace: default
6. spec:
7.   podSelector:
8.     matchLabels:
9.       app: my-app
10.   policyTypes:
11.   - Egress  #定义出口流量规则
12.   egress:
13.   - to:
14.     - ipBlock:
15.         cidr: 0.0.0.0/0  #允许Pod访问外部网络

复制代码

        该战略将完全隔离某个Pod的网络流量，既不允许它吸收流量，也不允许它发送流量：

1. apiVersion: networking.k8s.io/v1
2. kind: NetworkPolicy
3. metadata:
4.   name: deny-all
5.   namespace: default
6. spec:
7.   podSelector:
8.     matchLabels:
9.       app: isolated-pod  #目标Pod
10.   policyTypes:
11.   - Ingress  #不允许任何流量进入
12.   - Egress   #不允许任何流量离开

复制代码