cks详细学习笔记

工作流程

访问文件权限模式

匹配目录和文件

seccompProfile.type：

• Unconfined - 如果没有其他选择，Seccomp不会应用于容器进程（这是Kubernetes中的默认设置）。
• RuntimeDefault - 使用默认的容器运行时配置文件。
• Localhost - 指定自定有的profile文件。当type 为该值时，此时必须指定localhostProfile字段的值。

seccomp基本配置文件包括三个元素：

• defaultAction：在syscalls部分未定义的任何系统调用默认动作为允许
• syscalls

  names 系统调用名称，可以换行写多个
  SCMP_ACT_ERRNO 阻止系统调用

容器中的应用程序默认以root账号运行的，这个root与宿主机root账号是相同的，拥有大部分对Linux内核的系统调用权限，这样是不安全的，所以我们应该将容器以普通用户运行，减少应用程序对权限的使用。
可以通过两种方法设置普通用户：
• Dockerfile里使用USER指定运行用户
• K8s里指定spec.securityContext.runAsUser，指定容器默认用户UID
spec:
  securityContext:
    runAsUser: 1000 # 镜像里必须有这个用户UID
    fsGroup: 1000 # 数据卷挂载后的目录属组设置为该组
  containers:
  - image: lizhenliang/flask-demo:root
    name: web
    securityContext:
      allowPrivilegeEscalation: false # 不允许提权

容器中有些应用程序可能需要访问宿主机设备、修改内核等需求，在默认情况下，容器没这个有这个能力，因此这时会考虑给容器设置特权模式。
启用特权模式：
containers:
- image: lizhenliang/flask-demo:root
  name: web
  securityContext:
    privileged: true
启用特权模式就意味着，你要为容器提供了访问Linux内核的所有能力，这是很危险的，为了减少系统调用的供给，可以使用Capabilities为容器赋予仅所需的能力。

# 创建psp策略，创建之后admin用户就可以创建pod了，但是不能创建特权pod
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: deny-privilege
spec:
  privileged: false # 不允许特权Pod
# 下面是一些必要的字段
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  runAsUser:
    rule: RunAsAny 
  fsGroup:
    rule: RunAsAny
  volumes:
    - '*'

# 创建role1
kubectl create role role1 --verb=create,get,list,watch,delete --resource=pods
# 给用户hhf绑定role1，授权创建pod
kubectl create rolebinding rolebind1 --role=role1 --user=hhf
# 创建role2
kubectl create role role2 --verb=use --resource=podsecuritypolicy --resource-name=deny-privilege
# 给用户hhf绑定role2，准许创建pod
kubectl create rolebinding rolebind2 --role=role2 --user=hhf

hhf用户创建特权pod失败
# kubectl run test --image=nginx --kubeconfig=/root/cert/hhf-config --privileged=true
Error from server (Forbidden): pods "test" is forbidden: PodSecurityPolicy: unable to admit pod: [spec.containers[0].securityContext.privileged: Invalid value: true: Privileged containers are not allowed]

使用K8s的user调动Deployment控制器或者其他控制器部署pod时。而这些控制器在收到了我们的请求后，也会利用自己的Service Accounts完成后续操作。
如果Deployment控制器的SA没有被赋予访问运行Deployment操作的PSP规则的权限，就算我们使用admin这个默认的账号也无法完成Deployment的操作。
能创建deployment，但是pod没有部署

# 创建clusterrole
kubectl create clusterrole psp-deny-privilege --verb=use --resource=podsecuritypolicies --resource-name=deny-privilege
# 给Deployment控制器的SA授权去访问PSP（pod依然没有部署，需要给replicaset控制器的SA授权）
kubectl create clusterrolebinding crolebinding-deny-privilege --clusterrole=psp-deny-privilege --serviceaccount=kube-system:deployment-controller
# 给replicaset控制器的SA授权去访问PSP
kubectl create clusterrolebinding crolebinding-deny-privilege2 --clusterrole=psp-deny-privilege --serviceaccount=kube-system:replicaset-controller

或者直接给Kube-system命名空间内所有的SA做绑定
kubectl create clusterrolebinding crolebinding-deny-privilege3 --clusterrole=psp-deny-privilege --serviceaccount=kube-system:replicaset-controller

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: non-root
spec:
  privileged: false # 不允许特权Pod
  # 下面是一些必要的字段
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  runAsUser:
    rule: MustRunAsNonRoot 
  fsGroup:
    rule: RunAsAny
  volumes:
    - '*'

•Template：策略逻辑实现的地方，使用rego语言
•Contsraint：负责Kubernetes资源对象的过滤或者为Template提供输入参数

约束模板：
apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: blacklistimages
spec:
  crd:
    spec:
      names:
        kind: BlacklistImages
  targets:
  - rego: |
      package k8strustedimages

      images {
        image := input.review.object.spec.containers[_].image
        not startswith(image, "xx.163.com/")
        not startswith(image, "yy.163.com/")
      }

      violation[{"msg": msg}] {
        not images
        msg := "not trusted image!"
      }
    target: admission.k8s.gatekeeper.sh

约束：
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: BlacklistImages
metadata:
  generation: 1
  managedFields:
  name: pod-trusted-images
  resourceVersion: "14449"
spec:
  match:
    kinds:
    - apiGroups:
      - ""
      kinds:
      - Pod

验证OPA规则是否生效：
# 打tag
ctr i tag docker.io/library/busybox:latest xx.163.com/busybox:v1
# 尝试使用该镜像创建pod
kubectl run test --image=xx.163.com/busybox:v1
Error from server ([pod-trusted-images] not trusted image!): admission webhook "validation.gatekeeper.sh" denied the request: [pod-trusted-images] not trusted image!

约束模板：
apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: privileged 
spec:
  crd:
    spec:
      names:
        kind: privileged
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package admission
        violation[{"msg": msg}] { # 如果violation为true（表达式通过）说明违反约束
          containers = input.review.object.spec.template.spec.containers
          c_name := containers[0].name
          containers[0].securityContext.privileged # 如果返回true，说明违反约束
          msg := sprintf("提示：'%v'容器禁止启用特权！",[c_name])
         }
# 查看资源
kubectl get ConstraintTemplate

约束：
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: privileged
metadata:
  name: privileged
spec:
  match: # 匹配的资源
    kinds:
      - apiGroups: ["apps"]
        kinds:
        - "Deployment"
        - "DaemonSet"
        - "StatefulSet“
# 查看资源
kubectl get constraints

模板：
apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: image-check
spec:
  crd:
    spec:
      names:
        kind: image-check
      validation:
        openAPIV3Schema: 
          properties: # 需要满足条件的参数
            prefix:
              type: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package image
        violation[{"msg": msg}] { 
           containers = input.review.object.spec.template.spec.containers
           image := containers[0].image
           not startswith(image, input.parameters.prefix) # 镜像地址开头不匹配并取反则为true，说明违反约束
           msg := sprintf("提示：'%v'镜像地址不在可信任仓库！", [image])
         }

约束：
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: image-check
metadata:
name: image-check
spec:
match:
kinds:
- apiGroups: ["apps"] 
kinds:
- "Deployment"
- "DaemonSet"
- "StatefulSet"
parameters: # 传递给opa的参数
prefix: "lizhenliang/

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequiredlabels
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredLabels
      validation:
        # Schema for the `parameters` field
        openAPIV3Schema:
          type: object
          properties:
            labels:
              type: array
              items:
                type: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredlabels

        violation[{"msg": msg, "details": {"missing_labels": missing}}] {
          provided := {label | input.review.object.metadata.labels[label]}
          required := {label | label := input.parameters.labels[_]}
          missing := required - provided
          count(missing) > 0
          msg := sprintf("you must provide labels: %v", [missing])
        }

命名空间必须要有gatekeeper标签
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: ns-must-have-gk
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Namespace"]
  parameters:
    labels: ["gatekeeper"]

测试：
# kubectl create ns test2
Error from server (Forbidden): admission webhook "validation.gatekeeper.sh" denied the request: [ns-must-have-gk] you must provide labels: {"gatekeeper"}
加上gk标签：
apiVersion: v1
kind: Namespace
metadata:
  labels:
    gatekeeper: test
  name: test2

[root@master ~]# echo -n 123 |base64 MTIz

apiVersion: v1
kind: Secret
metadata:
  name: mysql
type: Opaque
data:
  mysql-root-password: "MTIz"
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql
spec:
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: db
        image: mysql:5.7.30
    env:
    - name: MYSQL_ROOT_PASSWORD
      valueFrom:
        secretKeyRef:
          name: mysql
          key: mysql-root-password

基于硬件虚拟化隔离

基于规则的安全隔离，seccomp、AppArmor 和 SELinux 等

gVisor的隔离机制

gVisor 由 3 个组件构成： 
• Runsc 是一种 Runtime 引擎，负责容器的创建与销毁。 
• Sentry 负责容器内程序的系统调用处理。
• Gofer 负责文件系统的操作代理，IO 请求都会由它转接到 Host 上。

gVisor内核要求：Linux 3.17+
CentOS7内核升级步骤：
rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-2.el7.elrepo.noarch.rpm
yum --enablerepo=elrepo-kernel install kernel-ml-devel kernel-ml –y
grub2-set-default 0
reboot
uname -r

1、准备gVisor二进制文件
sha512sum -c runsc.sha512
rm -f *.sha512
chmod a+x runsc
mv runsc /usr/local/bin
2、Docker配置使用gVisor
runsc install # 查看加的配置/etc/docker/daemon.json
systemctl restart docker

使用runsc运行容器：
docker run -d --runtime=runsc nginx
使用dmesg验证：
docker run --runtime=runsc -it nginx dmesg

切换Containerd容器引擎
1、准备配置
cat > /etc/sysctl.d/99-kubernetes-cri.conf << EOF
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF
sysctl -system
2、安装
cd /etc/yum.repos.d
wget http://mirrors.aliyun.com/dockerce/linux/centos/docker-ce.repo
yum install -y containerd.io
3、修改配置文件
• pause镜像地址
• Cgroup驱动改为systemd
• 增加runsc容器运行时
• 配置docker镜像加速器
mkdir -p /etc/containerd
containerd config default > /etc/containerd/config.toml
vi /etc/containerd/config.toml
...
[plugins."io.containerd.grpc.v1.cri"]
sandbox_image = "registry.aliyuncs.com/google_containers/pause:3.2" 
...
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
SystemdCgroup = true
...
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runsc]
runtime_type = "io.containerd.runsc.v1"
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
endpoint = ["https://b9pmyelo.mirror.aliyuncs.com"]
...
systemctl restart containerd
4、配置kubelet使用containered
vi /etc/sysconfig/kubelet 
KUBELET_EXTRA_ARGS=--container-runtime=remote --container-runtimeendpoint=unix:///run/containerd/containerd.sock --cgroup-driver=systemd
systemctl restart kubelet
5、验证
kubectl get node -o wide

Kube-bench是容器安全厂商Aquq推出的工具，以CIS K8s基准作为基础，来检查K8s是否安全部署。
主要查找不安全的配置参数、敏感的文件权限、不安全的帐户或公开端口等等。

1、下载二进制包
https://github.com/aquasecurity/kube-bench/releases

2、解压使用
tar zxvf kube-bench_0.6.3_linux_amd64.tar.gz 
mkdir /etc/kube-bench # 创建默认配置文件路径
mv cfg /etc/kube-bench/cfg

常用参数：
• -s, --targets 指定要基础测试的目标，这个目标需要匹配cfg/<version>中的
文件名称，已有目标：master, controlplane, node, etcd, policies
• --version：指定k8s版本，如果未指定会自动检测
• --benchmark：手动指定CIS基准版本，不能与--version一起使用

示例：检查master组件安全配置
kube-bench run --targets=master

测试项目配置文件：/etc/kube-bench/cfg/cis-1.6/
• id：编号
• text：提示的文本
• audit： 
• tests：测试项目
• remediation：修复方案
• scored：如果为true，kube-bench无法正常测试，
则会生成FAIL，如果为false，无法正常测试，则会
生成WARN。 
• type：如果为manual则会生成WARN，如果为skip，
则会生成INFO

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: test
spec:
  podSelector: {}  # 匹配本命名空间所有pod
  policyTypes: 
  - Ingress
  - Egress
  # ingress和egress没有指定规则，则不允许任何流量进出pod

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-namespaces 
  namespace: test
spec:
  podSelector: {} 
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector: {} # 匹配本命名空间所有pod

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-namespaces 
  namespace: test
spec:
  podSelector: 
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector: {} # 匹配所有命名空间的pod

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: app-to-app
  namespace: test
spec:
  podSelector:
    matchLabels:
      run: web
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
      matchLabels:
        run: client1
    ports:
    - protocol: TCP
      port: 80

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: dev-web
  namespace: dev
spec:
  podSelector:
    matchLabels:
      env: dev
  policyTypes:
  - Ingress
  ingress:
  # 满足允许prod命名空间中的pod访问
  - from:
    - namespaceSelector:
        matchLabels:
          env: prod
  # 允许pod标签为app=client1的pod访问，所有命名空间
  - from:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          app: client1

为指定用户授权访问default命名空间Pod读取权限
大致步骤：
1. 用K8S CA签发客户端证书
2. 生成kubeconfig授权文件
3. 创建RBAC权限策略
4. 指定kubeconfig文件测试权限：kubectl get pods --kubeconfig=./aliang.kubeconfig

先了解下ServiceAccount，简称SA，是一种用于让程序访问K8s API的服务账号。
• 当创建namespace时，会自动创建一个名为default的SA，这个SA没有绑定任何权限
• 当default SA创建时，会自动创建一个default-token-xxx的secret，并自动关联到SA
• 当创建Pod时，如果没有指定SA，会自动为pod以volume方式挂载这个default SA，在容器目录：/var/run/secrets/kubernetes.io/serviceaccount
验证默认SA权限：kubectl --as=system:serviceaccount:default:default get pods

需求：授权容器中Python程序对K8s API访问权限
实施大致步骤：
1. 创建Role
2. 创建ServiceAccount
3. 将ServiceAccount与Role绑定
4. 为Pod指定自定义的SA
5. 进入容器里执行Python程序测试操作K8s API权限

apiVersion: v1
kind: ResourceQuota
metadata:
  name: object-counts
  namespace: test
spec:
  hard:
    pods: "10"
    count/deployments.apps: "3"
    count/services: "3"

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
  namespace: test
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 10Gi
    limits.cpu: "6"
    limits.memory: 12Gi

apiVersion: v1
kind: ResourceQuota
metadata:
  name: storage-resources
  namespace: test
spec:
  hard:
    requests.storage: "10G"
    managed-nfsstorage.storageclass.storage.k8s.io/requests.storage: "5G"

kubectl get quota -n test

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-memory-min-max
  namespace: test
spec:
  limits:
  - max: # 容器能设置limit的最大值
      cpu: 1
      memory: 1Gi
    min: # 容器能设置request的最小值
      cpu: 200m 
      memory: 200Mi
    type: Container

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-memory-min-max 
  namespace: test
spec:
  limits:
  - default:
    cpu: 500m
    memory: 500Mi
  defaultRequest:
    cpu: 300m
    memory: 300Mi
  type: Container

apiVersion: v1
kind: LimitRange
metadata:
  name: storage-min-max
  namespace: test
spec:
  limits:
  - type: PersistentVolumeClaim
    max:
      storage: 10Gi
    min:
      storage: 1Gi