课题解析

第一章

1、网络策略

需求1：在test命名空间创建一个名为deny-all的网络策略，拒绝本命名空间所有Pod的Ingress和Egress流量

kubectl create namespace test
cat > deny-all-test.yaml << EOF
# 所有pod孤立的策略
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: test
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
EOF
cat > deny-ns-test.yaml << EOF
# 只限定本名称空间下的pod间相互通信
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-ns
  namespace: test
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          project: test
EOF

需求2：限制dev命名空间标签为env=dev的pod，只允许prod命名空间中的pod访问和其他所有命名空间app=client1标签pod访问

kubectl create namespace dev 
kubectl create namespace prod
kubectl label namespace prod project=prod
cat > allow-env-dev-pod.yaml << EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-env-dev
  namespace: dev
spec:
  podSelector:
    matchLabels:
      env: dev
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          project: prod
    - podSelector:
        matchLabels:
          app: client
EOF

• 指定标签的pod访问，未实现

第二章

1、权限访问

1、创建一个名为backend-sa的serviceaccount，授权只能查看default命名空间下pod，再创建一个deployment使用这个serviceaccount。

# 1.创建一个名为backend-sa的sa
kubectl create serviceaccount backend-sa
# 2.创建一个只能查看default名称空间下的role
kubectl create role get-pod-role --verb=get,list,watch --resource=pods --dry-run=client -o yaml > get-pod-role.yaml
# 3.创建一个rolebinding将backend-sa和get-pod-role绑定
kubectl create rolebinding backend-sa-role --role=get-pod-role --serviceaccount=default:backend-sa --dry-run=client -o yaml > backend-sa-role.yaml
# 4.测试
kubectl --as=system:serviceaccount:default:backend-sa get pods
# 5.创建一个deployment，并使用改sa查看
kubectl create deployment web --image=nginx
kubectl --as=system:serviceaccount:default:backend-sa get deployments
内容如下：没有权限
Error from server (Forbidden): deployments.apps is forbidden: User "system:serviceaccount:default:backend-sa" cannot list resource "deployments" in API group "apps" in the namespace "default"

2、资源限额

2、为default命名空间下创建的容器默认请求值（resources.requests）cpu=200m，memory=200Mi

apiVersion: v1
kind: LimitRange
metadata:
  name: limitrange-container
  namespace: default
spec:
  limits:
  - default:
      cpu: 200m
      memory: 200Mi
    defaultRequest:
      cpu: 200m
      memory: 200Mi
    type: Container

• 如果只设置了上限（default），则请求值（defaultRequest）和上限（default）相同

第三章

1、apparmor策略

1、在工作节点上加载课堂上讲解的apparmor策略文件k8s-deny-write，并在Pod中应用该策略

cat > /etc/apparmor.d/k8s-deny-write << EOF
#include <tunables/global>
profile k8s-deny-write flags=(attach_disconnected) {
  #include <abstractions/base>
  file,
  deny /tmp/** w,
  deny /data/www/** w,
}
EOF
apparmor_parser -a /etc/apparmor.d/k8s-deny-write 
root@k8s-master-1:/cks# apparmor_status | grep k8s
   k8s-deny-write

• 要在调度到的节点上加载apparmor（否则状态为Blocked）

cat apparmor-hello.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: hello-apparmor
  annotations:
    # Tell Kubernetes to apply the AppArmor profile "k8s-apparmor-example-deny-write".
    # Note that this is ignored if the Kubernetes node is not running version 1.4 or greater.
    container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-deny-write
spec:
  containers:
  - name: hello
    image: busybox
    command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]

2、seccomp

2、在工作节点上加载课堂上讲解的seccomp文件，禁止容器里使用chmod命令，并在Pod中应用该策略

cat !$
cat /var/lib/kubelet/seccomp/profiles/chmod.json
{
    "defaultAction": "SCMP_ACT_ALLOW",
    "syscalls": [
        {
            "names": [
                "chmod"
            ],
            "action": "SCMP_ACT_ERRNO"
        }
    ]
}

• 要在调度到的节点上创建，否则pod起不来
• 注意拒绝策略名词是：SCMP_ACT_ERRNO 而不是 SCMP_ACT_ERROR

cat seccomp-hello.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: hello-seccomp
spec:
  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: profiles/chmod.json
  containers:
  - name: hello-2
    image: busybox
    command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]

第四章

1、Pod安全上下文

示例1：容器默认没有挂载文件系统能力，添加SYS_ADMIN增加这个能力

cat sys-admin.yaml
apiVersion: v1
kind: Pod
metadata:
  name: sys-admin-pod
spec:
  containers:
  - name: test
    image: busybox
    command:
    - sleep
    - 24h
    securityContext:
      capabilities:
        add: ["SYS_ADMIN"]

案例2：只读挂载容器文件系统，防止恶意二进制文件创建

cat read-only.yaml
apiVersion: v1
kind: Pod
metadata:
  name: read-only
spec:
  containers:
  - name: read-only
    image: busybox
    command:
    - sleep
    - 24h
    securityContext:
      readOnlyRootFilesystem: true

2、PSP

1、创建一个PSP策略，防止创建特权Pod，再创建一个ServiceAccount，使用kubectl –as验证PSP策略效果

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: example
spec:
  privileged: false  # Don't allow privileged pods!
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  runAsUser:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  volumes:
  - '*'

# 创建SA
kubectl create serviceaccount geray
# 将SA绑定到系统内置Role
kubectl create rolebinding geray --clusterrole=edit --serviceaccount=default:geray
# 创建使用PSP权限的Role
kubectl create role psp:unprivileged --verb=use --resource=podsecuritypolicy --resource-name=psp-example
# 将SA绑定到Role
kubectl create rolebinding geray:psp:unprivileged --role=psp:unprivileged --serviceaccount=default:geray

cat privileged.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: test1
spec:
  containers:
  - name: web
    image: nginx
    securityContext:
      privileged: true
cat noPrivileged.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: test2
spec:
  containers:
  - name: web
    image: nginx
kubectl --as=system:serviceaccount:default:geray create -f privileged.yaml 
kubectl --as=system:serviceaccount:default:geray create -f noPrivileged.yaml

3、gVisor

2、使用containerd作为容器运行时，准备好gVisor，创建一个RuntimeClass，创建一个Pod在gVisor上运行