目录

1、Selinux AppArmor

2、k8s api安全：

3、k8s 网络安全：k8s 网络策略

kube-proxy

CNI    

 Service Mesh

Network Policy     

4、k8s pod安全： 

  RBAC 策略

  安全上下文

---

1、Selinux AppArmor

2、k8s api安全：

1. 处理好鉴权和授权问题
2. admission controllers

 总之，api请求需要证书，且api服务器接受api请求只能在安全的端口上

3、k8s 网络安全：k8s 网络策略

kube-proxy

        kube-proxy 部署在每个节点上，管理k8s集群内部的网络，抽象linux底层的网络

CNI    

        CNI 插件：创建容器使用的虚拟网络接口(veth pair)

 Service Mesh

        Service Mesh :服务网格，sidecar 分析流量，开源Istio

Network Policy     

 apiVersion: networking.k8s.io/v1
        kind: NetworkPolicy
        metadata:
        name: test-network-policy
        namespace: default
        spec:
        podSelector:
            matchLabels:
            role: db
        policyTypes:
        - Ingress
        - Egress
        ingress:
        - from:
            - ipBlock:
                cidr: 172.17.0.0/16
                except:
                - 172.17.1.0/24
            - namespaceSelector:
                matchLabels:
                project: myproject
            - podSelector:
                matchLabels:
                role: frontend
            ports:
            - protocol: TCP
            port: 6379
        egress:
        - to:
            - ipBlock:
                cidr: 10.0.0.0/24
            ports:
            - protocol: TCP
            port: 5978

    说明：
        spec: NetworkPolicy 规约 中包含了在一个命名空间中定义特定网络策略所需的所有信息。
        podSelector: 每个 NetworkPolicy 都包括一个 podSelector ，它对该策略所应用的一组 Pod进行选择。示例中的策略选择带有 "role=db" 标签的 Pod。空的 podSelector 选择命名空间下的所有 Pod。
        policyTypes: 每个 NetworkPolicy 都包含一个 policyTypes 列表，其中包含 Ingress 或 Egress 或两者兼具。policyTypes 字段表示给定的策略是否应用于进入所选 Pod 的入口流量或者来自所选 Pod的出口流量，或两者兼有。如果 NetworkPolicy 未指定 policyTypes 则默认情况下始终设置 Ingress，如果NetworkPolicy 有任何出口规则的话则设置 Egress。
        ingress: 每个 NetworkPolicy 可包含一个 ingress 规则的白名单列表。每个规则都允许同时匹配 from 和ports 部分的流量。示例策略中包含一条简单的规则： 它匹配一个单一的端口，来自三个来源中的一个， 第一个通过 ipBlock指定，第二个通过namespaceSelector 指定，第三个通过 podSelector 指定。
        egress: 每个 NetworkPolicy 可包含一个 egress 规则的白名单列表。每个规则都允许匹配 to 和 port部分的流量。该示例策略包含一条规则，该规则将单个端口上的流量匹配到 10.0.0.0/24 中的任何目的地。
    所以，该网络策略示例:
        隔离 “default” 命名空间下 “role=db” 的 Pod (如果它们不是已经被隔离的话)。
        （Ingress 规则）允许以下 Pod 连接到 “default” 命名空间下的带有 “role=db” 标签的所有 Pod 的6379 TCP 端口：
        “default” 命名空间下任意带有 “role=frontend” 标签的 Pod
        带有 “project=myproject” 标签的任意命名空间中的 Pod
        IP 地址范围为 172.17.0.0–172.17.0.255 和 172.17.2.0–172.17.255.255（即，除了
        172.17.1.0/24 之外的所有 172.17.0.0/16）
        （Egress 规则）允许从带有 “role=db” 标签的命名空间下的任何 Pod 到 CIDR 10.0.0.0/24 下 5978TCP 端口的连接。

转载：k8s networkpolicy网络策略详解_ghostwritten的博客-CSDN博客_networkpolicy

4、k8s pod安全： 

  RBAC 策略

  安全上下文

        安全上下文（Security Context）定义 Pod 或 Container 的特权与访问控制设置。安全上下文包括但不限于：

1. 自主访问控制（Discretionary Access Control）：基于 用户 ID（UID）和组 ID（GID）.来判定对对象（例如文件）的访问权限
2. 安全性增强的 Linux（SELinux）：为对象赋予安全性标签。
3. 以特权模式或者非特权模式运行。
4. Linux 权能: 为进程赋予 root 用户的部分特权而非全部特权。
5. AppArmor：使用程序文件来限制单个程序的权限。
6. Seccomp：限制一个进程访问文件描述符的权限。
7. AllowPrivilegeEscalation：控制进程是否可以获得超出其父进程的特权。此布尔值直接控制是否为容器进程设置no_new_privs 标志。当容器以特权模式运行或者具有 CAP_SYS_ADMIN权能时，AllowPrivilegeEscalation 总是为 true。
8. readOnlyRootFilesystem：以只读方式加载容器的根文件系统。

        安全上下文功能

1.   配置pod的安全上下文

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  volumes:
 - name: sec-ctx-vol
    emptyDir: {}
  containers:
 - name: sec-ctx-demo
    image: busybox
    command: [ "sh", "-c", "sleep 1h" ]
    volumeMounts:
    - name: sec-ctx-vol
      mountPath: /data/demo
    securityContext:
      allowPrivilegeEscalation: false

1. 在配置文件中，该runAsUser字段指定对于Pod中的任何容器，所有进程都以用户ID 1000运行。
2. 该runAsGroup字段为Pod中的任何容器中的所有进程指定主组ID3000。如果省略此字段，则容器的主要组ID将为root（0）。runAsGroup指定时，用户1000和组3000也将拥有所有创建的文件。
3. 由于fsGroup指定了字段，因此容器的所有进程也是补充组ID2000的一部分。卷的所有者/data/demo和在该卷中创建的任何文件都将是组ID 2000。

        为 Pod 配置卷访问权限和属主变更策略

        默认情况下，Kubernetes 在挂载一个卷时，会递归地更改每个卷中的内容的属主和访问权限，使之与 Pod 的 securityContext 中指定的 fsGroup 匹配。对于较大的数据卷，检查和变更属主与访问权限可能会花费很长时间，降低 Pod 启动速度。你可以在 securityContext 中使用 fsGroupChangePolicy 字段来控制 Kubernetes 检查和管理卷属主和访问权限的方式。

        fsGroupChangePolicy - fsGroupChangePolicy 定义在卷被暴露给 Pod 内部之前对其 内容的属主和访问许可进行变更的行为。此字段仅适用于那些支持使用 fsGroup 来 控制属主与访问权限的卷类型。此字段的取值可以是：

1. OnRootMismatch：只有根目录的属主与访问权限与卷所期望的权限不一致时，才改变其中内容的属主和访问权限。这一设置有助于缩短更改卷的属主与访问权限所需要的时间。
2. Always：在挂载卷时总是更改卷中内容的属主和访问权限。

   securityContext:
     runAsUser: 1000
     runAsGroup: 3000
     fsGroup: 2000
     fsGroupChangePolicy: "OnRootMismatch"
   

   对启动的容器使用sysctl修改内核参数

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: sc-demo
spec:
  template:
    containers:
    - name: sc-demo
      image: xxxxxx
      command: [ "sh", "-c", "sleep 1h" ]
      securityContext:
        capabilities:
            add: ["SYS_ADMIN"]

对启动的容器赋予SELinux标签
 

...
securityContext:
  seLinuxOptions:
    level: "s0:c123,c456"

转自：Kubernetes【安全】1. SecurityContext安全上下文_ghostwritten的博客-CSDN博客_k8s 安全上下文