CKS学习笔记：集群安全部分

 

 

CKS学习笔记—NetworkPolicy

 

NetworkPolicy用于限制Kubernetes中pod之间的互相访问，类似于传统网络中的防火墙。在Kubernetes不配置NetworkPolicy的情况下，pod直接是可以访问的，也就是默认是开放的。

 

下面是一个 Kubernetes官方给出的NetworkPolicy例子。（注意这个例子官方网站的例子有错，我是2022年6月底看到，不确定官方什么时候修改，其中“- from”开始的缩进有问题，下面显示的格式，我已经修改好了）

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

现在对这个例子中的字段进行说明：

固定字段：包括apiVersion，kind，metadata。

Spec：包括NetworkPolicy的所有信息。

podSelector：每个NetworkPolicy都包含这个字段，这个字段用于选择哪些pod受这个NetworkPolicy的控制，比如上述例子中就是通过label “role=DB”来选择pod。如果podSelector为空的话，就是选择在这个namespace中的所有pod。

policyTypes：每个NetworkPolicy都包含一个policyTypes列表，可以包含Ingress，Egress任意一个或同时包含两个。

ingress：每个NetworkPolicy可以包含ingress规则列表，每条规则允许通过from和ports来匹配，上述例子中就是匹配一个端口和三个源中任意一个，三个源是通过ipBlock，namespace和podSelector来实现。

 

egress：每个NetworkPolicy可以包含egress规则列表，每条规则允许通过to和ports来匹配，上述例子中就是匹配一个端口和一个地址段。

 

因此，上述例子的NetworkPolicy就是：

1.在“default”namespace中带有“role=db”label的pod，对ingress和egress流量做控制。

2.ingress规则：允许符合下面三个条件之一的流量来访问“default”namespace中带有“role=db”label pod的TCP 6379端口。

a.“default”namespace中带有“role=frontend”label的pod

b.带有“project=myproject”label namespace中的所有pod

c.除172.16.1.0/24之外的172.16.0.0/16 IP地址的所有pod

3.egress规则：允许“default”namespace中带有“role=db”label 的pod访问10.0.0.0/24地址段的TCP 5978端口。

 

to和from字段说明

在ingress from字段和egress to字段有四种选择器：

podSelector：选择pod

namespaceSelector： 选择namespace

namespaceSelector和podSelector：需要同时命中namespace和pod，

ipBlock：选择IP地址段

注意下面两种语法，意思是不一样的：

 

...

ingress:

- from:

  - namespaceSelector:

      matchLabels:

        user: alice

    podSelector:

      matchLabels:

        role: client

...

 

...

ingress:

- from:

  - namespaceSelector:

      matchLabels:

        user: alice

  - podSelector:

      matchLabels:

         role: client

...

 

第一种语法是同时符合namespace和pod label的流量，namespace和pod是“与”的关系。

第二种语法是符合namespace或pod label其中之一的流量，namespace和pod是“或”的关系。

 

 

五种常用默认策略：

 

阻断所有ingress流量：

---

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

  name: default-deny-ingress

spec:

  podSelector: {}

  policyTypes:

  - Ingress

 

允许所有ingress流量：

---

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

  name: allow-all-ingress

spec:

  podSelector: {}

  ingress:

  - {}

  policyTypes:

  - Ingress

 

阻断所有egress流量：

---

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

  name: default-deny-egress

spec:

  podSelector: {}

  policyTypes:

  - Egress

 

允许所有egress流量：

---

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

  name: allow-all-egress

spec:

  podSelector: {}

  egress:

  - {}

  policyTypes:

  - Egress

 

阻断所有ingress和egress流量

---

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

  name: default-deny-all

spec:

  podSelector: {}

  policyTypes:

  - Ingress

  - Egress

 

根据这五种默认策略总结：

podSelector中配置“podSelector: {}”就是匹配所有流量；

在policyTpes中配置“- ingress”或“- Egress”，不配置ingress或Egress规则，则阻断流量；

在policyTpes中配置“- ingress”或“- Egress”，同时配置ingress或Egress规则“- {}”，则就是允许流量；

在policyTpes中不配置“- ingress”或“- Egress”，则允许流量。

 

 

CKS学习笔记—CIS Benchmarks

 

CIS：Center for Internet Security，是一个专注提升数字安全的非盈利组织。

 

CIS Benchmarks是一组在系统安全方面，以共识为导向的社区标准和最佳实践。

CIS Kubernetes Benchmark 为Kubernetes安全环境提供了准则。

 

Kube-bench是一个工具，它可以确认K8s集群的配置是否符合CIS Kubernetes Benchmark。

 

在k8s中可以将Kube-bench当做一个job来运行，kube-bench的yaml文件分为master和node：

https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job-master.yaml

https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job-node.yaml

 

可以通过wget -O kube-bench-control-plan.yaml https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job-master.yaml

和

wget -O kube-bench-node.yaml https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job-node.yaml

下载这两个yaml文件。

 

运行kube-bench

Kubectl create -f kube-bench-control-plane.yaml

Kubectl create -f kube-bench-node.yaml

 

查看kub-bench运行状态以及pod的名称

Kubectl get pods

NAME READY STATUS RESTARTS AGE

kube-bench-master-qbzzx 0/1 Completed 0 10s

kube-bench-master-qbzzx 0/1 Completed 0 5s

 

保存kube-Bench的日志

Kubectl logs kube-bench-master-qbzzx > kube-bench-results-control-plane.log

Kubectl logs kube-bench-master-qbzzx > kube-bench-results-node.log

 

 

查看结果：

cat kube-bench-results-control-plane.log

cat kube-bench-results-node.log

 

可以先看最后的总结（类似的内容）：

== Summary master ==

45 checks PASS

10 checks FAIL

10 checks WARN

0 checks INFO

 

在回看control-plane的详细内容，在CKS考试中可能会遇到的失败信息：

[FAIL] 1.2.20 Ensure that the --profiling argument is set to false (Automated)

 

[FAIL] 1.3.2 Ensure that the --profiling argument is set to false (Automated)

 

[FAIL] 1.4.1 Ensure that the --profiling argument is set to false (Automated)

 

在Remediations master中能看到修复方法

 

1.2.20 Edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml the master node and set the below parameter.

--profiling=false

 

1.3.2 Edit the Controller manager pod specification file /etc/kubernetes/manifests/kube-controller-manager.yaml on the master node and set the below parameter.

--profiling=false

 

1.4.1 Edit the Scheduler pod specification file /etc/kubernetes/manifests/kube-scheduler.yaml on the master node and set the below parameter.

--profiling=false

 

然后根据上述信息进行修复

sudo vi etc/kubernetes/manifests/kube-apiserver.yaml，

在该yaml文件中的- kube-apiserver下面增加一行“- --profiling=false”

保存。

 

sudo vi etc/kubernetes/manifests/kube-controller-manager.yaml，

在该yaml文件中的- kube-controller-manager下面增加一行“- --profiling=false”

保存。

 

sudo vi etc/kubernetes/manifests/kube-scheduler.yaml，

在该yaml文件中的- kube-controller-manager下面增加一行“- --profiling=false”

保存。

 

查看上述三个pod的启动情况：kubectl get pods -n kube-system

 

在回看node的详细内容，在CKS考试中可能会遇到的失败信息：

[FAIL] 4.2.2 Ensure that the --authorization-mode argument is not set to AlwaysAllow (Automated)

 

在Remediations master中能看到修复方法

 

4.2.2 If using a Kubelet config file, edit the file to set authorization: mode to Webhook. If using executable arguments, edit the kubelet service file /etc/systemd/system/kubelet.service.d/10-kubeadm.conf on each worker node and set the below parameter in KUBELET_AUTHZ_ARGS variable.

--authorization-mode=Webhook

Based on your system, restart the kubelet service. For example:

Systemctl daemon-relaod

Systemctl restarat kubelet.service

 

然后根据上述信息进行修复

首先通过cat etc/systemd/system/kubelet.service.d/10-kubeadm.conf查看kubelet配置文件，可以通过

Environment=”KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml”

获得配置文件为“/var/lib/kubelet/config.yaml”

 

然后修改该文件中的参数：sudo vi /var/lib/kubelet/config.yaml

在该yaml文件中的authorization下面的mode的值修改为Webhook。同时注意其中的authentication下面的webhook的enabled值应为true

 

重新启动一下kubelet：sudo systemctl restarat kubelet

查看上述三个pod的启动情况：kubectl get pods -n kube-system

 

 

CKS学习笔记—TLS with Ingress

 

Ingress是Kubernetes对外发布服务的一个对象，外部用户可以通过Ingress访问Kubernetes内部pod提供的服务。

Ingress可以提供TLS终结，TLS是Transport Layer Security的缩写，提供客户端到服务端的端到端加密，实现访问的链路安全。

 

TLS with Ingress，是用户到Ingress之间进行加密，也就是用户端到Ingress之间使用https协议，Ingress和pod之间使用http协议。

 

实现TLS需要有证书和key，在Kubernetes中，可以使用Secret来保存证书和key。

 

例如：

apiVersion: v1

kind: Secret

metadata:

  name: testsecret-tls

  namespace: default

data:

  tls.crt: base64 encoded cert

  tls.key: base64 encoded key

type: kubernetes.io/tls

 

配置Secret后，再配置Ingress：

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

  name: tls-example-ingress

spec:

  tls:

  - hosts:

    - https-example.foo.com

    secretName: testsecret-tls

  rules:

  - host: https-example.foo.com

    http:

      paths:

      - path: /

        pathType: Prefix

        backend:

          service:

            name: service1

            port:

              number: 80

 

 

 

CKS学习笔记—确认Kubernetes二进制文件

 

二进制文件是Kubernete组件的可执行文件，包括kubectl，kubeadm，kubelet

 

在安装之间可以手动校验二进制文件的正确性，通过checksum来确定二进制文件没有被篡改，将checksum校验的结果和从官方网站下载的chacksum文件进行对比就知道该文件是否被篡改。

 

如果是已经安装的系统，首先要确定版本信息：kubectl version --short --client

 

获取版本信息后，到官网下载sha256文件：

Curl -LO https://dl.k8s.io/v1.20.1/bin/linux/amd64/kubectl.sha256

 

在通过下面命令进行确认：

echo "$(cat kubectl.sha256) kubectl" | sha256sum --check

或

echo "$(<kubectl.sha256) /usr/bin/kubectl" | sha256sum --check

 

如果输出为：

Kubectl: OK

或

/usr/bin/kubectl: OK

 

则标明该二进制文件没问题。

 

 

如果输出为：

Kubectl: FAILED

Sha256sum: WARNING: 1 computed checksum dis NOT match

则说明该二进制文件已经被篡改。