CKS认证 | Day1 K8s集群部署与安全设置

钜形不锈钢水箱 · 2025-1-22 16:30:22

马上注册，结交更多好友，享用更多功能，让你轻松玩转社区。

您需要登录才可以下载或查看，没有账号？立即注册

x

一、K8s安全运维概述

Kubernetes（K8s）是一个广泛利用的容器编排平台，用于自动化部署、扩展和管理容器化应用步伐。随着 K8s 在生产环境中的遍及，安全运维成为确保系统稳定性和数据安全的关键。

1.1 安全运维的紧张性

万物互联，安全为基，企业的网络安全不可小视；
服务器被黑事件频发；
公司紧张数据资产在运维手中；

— SecDevOps

SecDevOps 与 DevOps相似，是一种哲学，鼓励运维人员、开发人员、测试人员和安全人员举行更高水水平协作，将信息安全被放在事前考虑，将安全性注入自动化流程中，以确保整个产物周期内的信息安全。

1.2 K8s提供的安全机制

为保证集群以及容器应用的安全，Kubernetes 提供了多种安全机制，限定容器的举动，淘汰容器和集群的攻击面，保证整个系统的安全性。

集群安全：TLS证书认证、RBAC；
Security Context：限定容器的举动，例如只读文件系统、特权、运行用户等；
Pod Security Policy：集群级的 Pod 安全计谋，自动为集群内的 Pod 设置安全计谋；
Sysctls：允许容器设置内核参数；
AppArmor：限定容器中应用对资源的访问权限；
Network Policies：控制集群中网络通信；
Seccomp：限定容器内进程的系统调用；

1.3 K8s安全运维实践思路

二、部署一套完整的K8s高可用集群

请移步：CKS认证 | 利用kubeadm部署K8s高可用集群（v1.26）-CSDN博客

三、CIS 安全基准介绍

3.1 CIS 介绍

CIS（Center for Internet Security）安全基准 是由 CIS 组织订定的一套安全标准，旨在帮助组织评估和改进其系统和应用步伐的安全性。CIS 基准提供了一套具体的设置指南和最佳实践，通过遵循 CIS 基准，组织可以明显进步系统和应用步伐的安全性，降低潜在的安全风险。利用 CIS-CAT 等自动化工具，可以简化评估和修复过程，确保系统和应用步伐符合 CIS 基准的要求。紧张用于掩护常见的操作系统和软件平台免受已知的安全威胁。
互联网安全中心（CIS，Center for Internet Security），是一个非盈利组织，致力为互联网提供免费的安全防御解决方案。

CIS官网：https://www.cisecurity.org/
Kubernetes CIS基准方案：https://www.cisecurity.org/benchmark/kubernetes/

CIS 安全基准的核心概念：

1）目的

进步安全性：通过标准化设置和最佳实践，淘汰系统和应用步伐的毛病
降低风险：帮助组织识别和修复潜在的安全题目
合规性：满足行业标准和法规要求（如 PCI-DSS、HIPAA）

2）实用范围

操作系统：如 Windows、Linux（如 Ubuntu、Red Hat）、macOS
网络设备：如防火墙、路由器、互换机
云平台：如 AWS、Azure、GCP
容器编排平台：如 Kubernetes（K8s）

CIS 安全基准的紧张构成部分：
(1) 控制项（CIS Controls）

定义：一系列高优先级的安全实践，用于掩护组织的核心资产
特点：分为多个级别（Level 1、Level 2、Level 3），每个级别对应不同的安全需求
- Level 1：根本的安全实践，实用于全部组织
- Level 2：实用于中型和大型组织，提供更严格的安全控制
- Level 3：实用于高安全需求的场景，如政府和金融机构

(2) 设置基准（CIS Benchmarks）

定义：针对特定操作系统、应用步伐或平台的具体设置指南
内容：包括安全设置的最佳实践、建媾和查抄项
示例：
- Linux 系统：禁用不必要的服务、设置防火墙规则
- Kubernetes：启用 RBAC、设置网络计谋
- AWS：启用多因素认证（MFA）、设置 IAM 计谋

(3) 自动化工具（CIS-CAT）

定义：CIS 提供的自动化工具，用于评估系统和应用步伐是否符合 CIS 基准
功能：
- 扫描系统和应用步伐，查抄是否符合 CIS 基准
- 天生具体的陈诉，列出不符合的设置项
- 提供修复建议

3.2 K8s基准测试工具kube-bench

kube-bench 是由 Aqua Security 开发的一款开源工具，专门用于评估 Kubernetes 集群是否符合 CIS（Center for Internet Security）Kubernetes 基准。CIS 基准提供了一套针对 Kubernetes 的安全设置最佳实践，而 kube-bench 通过自动化扫描集群，帮助用户发现并修复不符合 CIS 基准的设置题目。以CIS K8s基准作为根本，用该工具来查抄K8s是否安全部署。紧张查找不安全的设置参数、敏感的文件权限、不安全的帐户或公开端口等等。

Github项目地址：https://github.com/aquasecurity/kube-bench

3.2.1 kube-beach部署

1）下载二进制包

https://github.com/aquasecurity/kube-bench/releases

2）解压tar包即可利用

tar zxvf kube-bench_0.6.14_linux_amd64.tar.gz
# 创建默认配置文件路径
mkdir /etc/kube-bench
mv cfg/ /etc/kube-bench/
[root@k8s-master-1-71 ~]# ls /etc/kube-bench/cfg/
ack-1.0 cis-1.23 cis-1.6 eks-1.0.1 gke-1.0 rh-1.0
aks-1.0 cis-1.24 cis-1.6-k3s eks-1.1.0 gke-1.2.0
cis-1.20 cis-1.5 config.yaml eks-stig-kubernetes-v1r6 rh-0.7
[root@k8s-master-1-71 ~]# ls /etc/kube-bench/cfg/cis-1.24/
config.yaml etcd.yaml node.yaml
controlplane.yaml master.yaml policies.yaml
# 将解压的kube-bench执行程序，移动到二进制目录下
mv kube-bench /usr/bin/

复制代码

3.2.2 kube-beach利用

Kube-bench 与 k8s 版本支持参考：https://github.com/aquasecurity/kube-bench/blob/main/docs/platforms.md#cis-kubernetes-benchmark-support

Source	Kubernetes Benchmark	kube-bench config	Kubernetes versions
CIS	1.5.1	cis-1.5	1.15
CIS	1.6.0	cis-1.6	1.16-1.18
CIS	1.20	cis-1.20	1.19-1.21
CIS	1.23	cis-1.23	1.22-1.23
CIS	1.24	cis-1.24	1.24
CIS	GKE 1.0.0	gke-1.0	GKE
CIS	GKE 1.2.0	gke-1.2.0	GKE
CIS	EKS 1.0.1	eks-1.0.1	EKS
CIS	EKS 1.1.0	eks-1.1.0	EKS
CIS	ACK 1.0.0	ack-1.0	ACK
CIS	AKS 1.0.0	aks-1.0	AKS
RHEL	RedHat OpenShift hardening guide	rh-0.7	OCP 3.10-3.11
CIS	OCP4 1.1.0	rh-1.0	OCP 4.1-
CIS	1.6.0-k3s	cis-1.6-k3s	k3s v1.16-v1.24
DISA	Kubernetes Ver 1, Rel 6	eks-stig-kubernetes-v1r6	EKS

利用 kube-bench --help 查察帮助
利用 kube-bench run 举行测试，该指令有以下常用参数：

常用参数：

-s, --targets 指定要根本测试的目的，这个目的需要匹配 cfg/ 中的 YAML文件名称，例如：

ls /etc/kube-bench/cfg/cis-1.24/

config.yaml etcd.yaml node.yaml

controlplane.yaml master.yaml policies.yaml

--version：指定k8s版本，如果未指定会自动检测；（目前支持k8s最高为1.24版本）
--benchmark：手动指定CIS基准版本，不能与--version一起利用；

示例1：查抄master组件安全设置（通过修复方案建议举行设置修改）

命令：kube-bench run --targets=master

执行后会逐个查抄安全设置并输出修复方案及汇总信息输出：

[PASS]：测试通过
  [FAIL]：测试未通过，重点关注，在测试结果会给出修复建议
  [WARN]：告诫，可做相识
  [INFO]：信息

示例2：测试项目设置文件：vi /etc/kube-bench/cfg/cis-1.24/目的文件.yaml（直接修改设置文件）

id：编号（与CIS安全基准PDF的ID对应）
text：提示的文本
audit：
tests：测试项目
remediation：修复方案
scored：如果为true，kube-bench无法正常测试，则会天生FAIL，如果为false，无法正常测试，则会天生WARN。
type：如果为manual则会天生WARN，如果为skip，则会天生INFO

[root@k8s-master-1-71 ~]# kube-bench run --targets=master
## FAIL 审计问题
[FAIL] 1.1.12 Ensure that the etcd data directory ownership is set to etcd:etcd (Automated)
[FAIL] 1.2.5 Ensure that the --kubelet-certificate-authority argument is set as appropriate (Automated)
[FAIL] 1.2.17 Ensure that the --profiling argument is set to false (Automated)
[FAIL] 1.2.18 Ensure that the --audit-log-path argument is set (Automated)
[FAIL] 1.2.19 Ensure that the --audit-log-maxage argument is set to 30 or as appropriate (Automated)
[FAIL] 1.2.20 Ensure that the --audit-log-maxbackup argument is set to 10 or as appropriate (Automated )
[FAIL] 1.2.21 Ensure that the --audit-log-maxsize argument is set to 100 or as appropriate (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.1.12 On the etcd server node, get the etcd data directory, passed as an argum
from the command 'ps -ef | grep etcd'.
Run the below command (based on the etcd data directory found above).
For example, chown etcd:etcd /var/lib/etcd //etcd数据目录设置属组
1.2.5 Follow the Kubernetes documentation and setup the TLS connection between
the apiserver and kubelets. Then, edit the API server pod specification file
/etc/kubernetes/manifests/kube-apiserver.yaml on the control plane node and set
--kubelet-certificate-authority parameter to the path to the cert file for the
--kubelet-certificate-authority=<ca-string>
1.2.9 Follow the Kubernetes documentation and set the desired limits in a confi
Then, edit the API server pod specification file /etc/kubernetes/manifests/kube
and set the below parameters.
--enable-admission-plugins=...,EventRateLimit,...
--admission-control-config-file=<path/to/configuration/file>
1.2.17 Edit the API server pod specification file /etc/kubernetes/manifests/kub
on the control plane node and set the below parameter.
--profiling=false
1.2.18 Edit the API server pod specification file /etc/kubernetes/manifests/kub
on the control plane node and set the --audit-log-path parameter to a suitable
file where you would like audit logs to be written, for example,
--audit-log-path=/var/log/apiserver/audit.log
1.2.19 Edit the API server pod specification file /etc/kubernetes/manifests/kub
on the control plane node and set the --audit-log-maxage parameter to 30
or as an appropriate number of days, for example,
--audit-log-maxage=30
1.2.20 Edit the API server pod specification file /etc/kubernetes/manifests/kub
on the control plane node and set the --audit-log-maxbackup parameter to 10 or
value. For example,
--audit-log-maxbackup=10
1.2.21 Edit the API server pod specification file /etc/kubernetes/manifests/kub
on the control plane node and set the --audit-log-maxsize parameter to an appro
For example, to set it as 100 MB, --audit-log-maxsize=100
1.3.2 Edit the Controller Manager pod specification file /etc/kubernetes/manifeager.yaml
on the control plane node and set the below parameter.
--profiling=false
1.4.1 Edit the Scheduler pod specification file /etc/kubernetes/manifests/kube-
on the control plane node and set the below parameter.
--profiling=false
== Summary master ==
40 checks PASS
9 checks FAIL
12 checks WARN
0 checks INFO
== Summary total ==
40 checks PASS
9 checks FAIL
12 checks WARN
0 checks INFO

复制代码

根据示例1，以 ID为 1.2.17 为例，建议将DEBUG参数功能设置为false：

1.2.17 Edit the API server pod specification file /etc/kubernetes/manifests/kub

on the control plane node and set the below parameter.

--profiling=false

未知参数，可以通过CIS PDF查找到相应位置，并通过官网的官方文档-【参考-组件工具】举行Ctrl -F 搜索

文档：kube-apiserver | Kubernetes

解释：该参数是通过 Web 接口 host:port/debug/pprof/ 默认启用的性能分析服务，用来举行DEBUG作用

curl -k https://192.168.1.71:6443/debug/pprof 大概kubectl get --raw=/debug/pprof

[root@k8s-master-1-71 ~]# vi /etc/kubernetes/manifests/kube-apiserver.yaml
spec:
containers:
- command:
...
- --profiling=false //末尾增加该参数
# 修改后保存，kube-apiserver自动重启
[root@k8s-master-1-71 ~]# kubectl get pods -n kube-system
...
kube-apiserver-k8s-master-1-71 1/1 Running 0 38s
# 重新执行
[root@k8s-master-1-71 ~]# kube-bench run --targets=master
[PASS] 1.2.17 Ensure that the --profiling argument is set to false (Automated)

复制代码

根据示例2，以 ID为 1.2.5 为例，通过更改设置文件，将告警等级举行降级：

[root@k8s-master-1-71 ~]# vi /etc/kube-bench/cfg/cis-1.24/master.yaml
...
- id: 1.2.5
text: "Ensure that the --kubelet-certificate-authority argument is set as appropriate (Automated)"
audit: "/bin/ps -ef | grep $apiserverbin | grep -v grep"
tests:
test_items:
- flag: "--kubelet-certificate-authority"
remediation: |
Follow the Kubernetes documentation and setup the TLS connection between
the apiserver and kubelets. Then, edit the API server pod specification file
$apiserverconf on the control plane node and set the
--kubelet-certificate-authority parameter to the path to the cert file for the certificate authority.
--kubelet-certificate-authority=<ca-string>
scored: false //将true设置为false。测试ID 1.2.5 从[FAIL] 变为 [WARN]
[root@k8s-master-1-71 ~]# kube-bench run --targets=master | grep 1.2.5
[WARN] 1.2.5 Ensure that the --kubelet-certificate-authority argument is set as appropriate (Automated)
[root@k8s-master-1-71 ~]# vi /etc/kube-bench/cfg/cis-1.24/master.yaml
scored: false
type: skip //增加type，值为skip。测试ID 1.2.5 从[WARN] 变为 [INFO]
[root@k8s-master-1-71 ~]# kube-bench run --targets=master | grep 1.2.5
[INFO] 1.2.5 Ensure that the --kubelet-certificate-authority argument is set as appropriate (Automated)

复制代码

四、Ingress 设置证书

4.1 Ingress介绍

Ingress：K8s中的一个抽象资源，给管理员提供一个暴露应用的入口定义方法；
Ingress Controller：根据Ingress天生具体的路由规则，并对Pod负载均衡器；

4.2 HTTPS紧张性

HTTPS是安全的HTTP，HTTP 协议中的内容都是明文传输，HTTPS 的目的是将这些内容加密，确保信息传输安全。最后一个字母 S 指的是SSL/TLS 协议，它位于 HTTP 协议与 TCP/IP 协议中心。

HTTPS上风：

加密隐私数据：防止您访客的隐私信息(账号、地址、手机号等)被挟制或偷取；
安满身份认证：验证网站的真实性，防止钓鱼网站；
防止网页篡改：防止数据在传输过程中被篡改，掩护用户体验；
地址栏安全锁：地址栏头部的“锁”型图标，进步用户信托度；
进步SEO排名：进步搜索排名次序，为企业带来更多访问量；

4.3 将一个项目对外暴露HTTPS访问

设置ingress服务

kubectl apply -f ingress-controller-1.1.yaml
[root@k8s-master-1-71 ~]# kubectl get pods -n ingress-nginx
NAME READY STATUS RESTARTS AGE
ingress-nginx-controller-85cdb79d-srkrq 1/1 Running 0 52s
[root@k8s-master-1-71 ~]# kubectl get svc -n ingress-nginx
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
ingress-nginx-controller NodePort 10.108.162.206 <none> 80:30513/TCP,443:32099/TCP 79d
ingress-nginx-controller-admission ClusterIP 10.103.217.175 <none> 443/TCP 79d

复制代码

设置HTTPS步调：

准备域名证书文件（来自：openssl / cfssl工具自签大概权威机构颁发）
将证书文件保存到Secret
Ingress规则设置tls
kubectl get ingress
测试，本地电脑绑定hosts纪录对应ingress里面设置的域名，IP是 Ingress Concontroller Pod节点IP

先前准备：

kubectl create deployment httpd-web --image=nginx --replicas=3
kubectl expose deployment httpd-web --port=80 --target-port=80

复制代码

步调1：准备域名证书文件

vi certs.sh
cat > ca-config.json <<EOF # 根证书的配置文件
{
"signing": {
"default": {
"expiry": "87600h"
},
"profiles": {
"kubernetes": {
"expiry": "87600h",
"usages": [
"signing",
"key encipherment",
"server auth",
"client auth"
]
}
}
}
}
EOF
cat > ca-csr.json <<EOF # 根证书的请求颁发文件
{
"CN": "kubernetes",
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"L": "Beijing",
"ST": "Beijing"
}
]
}
EOF
# 通过以上相关根证书信息，为指定域名颁发客户端证书
cfssl gencert -initca ca-csr.json | cfssljson -bare ca -
cat > web.hostname.cn-csr.json <<EOF
{
"CN": "web.hostname.cn", # 一定要与访问的实际域名保持一致
"hosts": [],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"L": "BeiJing",
"ST": "BeiJing"
}
]
}
EOF
cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes web.hostname.cn-csr.json | cfssljson -bare web.hostname.cn
[root@k8s-master-1-71 ~]# mkdir ssl ; mv certs.sh ssl/ ; cd ssl/
[root@k8s-master-1-71 ssl]# bash certs.sh

复制代码

步调2：将证书文件保存到Secret

kubectl create secret tls web-aliangedu-cn --
cert=web.aliangedu.cn.pem --key=web.aliangedu.cn-key.pem

复制代码

步调3：Ingress规则设置tls

[root@k8s-master-1-71 ~]# kubectl apply -f ingress-https.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress-https
spec:
ingressClassName: nginx
tls: # 添加tls
- hosts:
- httpd.hostname.cn
secretName: web-hostname-cn
rules:
- host: httpd.hostname.cn
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: httpd-web
port:
number: 80

复制代码

查察 kubectl get ingress

[root@k8s-master-1-71 ~]# kubectl get ingress
NAME CLASS HOSTS ADDRESS PORTS AGE
ingress-https nginx httpd.hostname.cn 192.168.1.73 80, 443 65s
[root@k8s-master-1-71 ~]# kubectl get svc -n ingress-nginx
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
ingress-nginx-controller NodePort 10.108.162.206 <none> 80:30513/TCP,443:32099/TCP 79d
ingress-nginx-controller-admission ClusterIP 10.103.217.175 <none> 443/TCP 79d

复制代码

访问测试：https://httpd.hostname.cn

五、网络计谋控制集群内部网络通信

5.1 网络计谋应用场景

默认情况下，Kubernetes 集群网络没任何网络限定，Pod 可以与任何其他 Pod 通信，在某些场景下就需要举行网络控制，淘汰网络攻击面，进步安全性，这就会用到网络计谋。

网络计谋（Network Policy）：是一个K8s资源，用于限定Pod收支流量，提供Pod级别和Namespace级别网络访问控制。

网络计谋的应用场景：

应用步伐间的访问控制，例如项目A不能访问项目B的Pod；
开发环境定名空间不能访问测试环境定名空间Pod；
当Pod暴露到外部时，需要做Pod白名单；
多租户网络环境隔离；

5.2 网络计谋概述

网络计谋工作流程：

创建Network Policy资源
Policy Controller监控网络计谋，同步并通知节点上步伐
节点上DaemonSet运行的步伐从etcd中获取Policy，调用本地Iptables创建防火墙规则

相关YAML文件：网络计谋 | Kubernetes

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

复制代码

podSelector：目的Pod，根据标签选择。
policyTypes：计谋范例，指定计谋用于入站、出站流量。
Ingress：from是可以访问的白名单，可以来自于IP段、定名空间、
Pod标签等，ports是可以访问的端口。
Egress：这个Pod组可以访问外部的IP段和端口。

5.3 网络访问控制5个案例

案例1：拒绝定名空间下全部Pod入、出站流量

需求：拒绝test定名空间下全部Pod入、出站流量

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

复制代码

案例2：拒绝其他定名空间Pod访问

需求：test定名空间下全部pod可以相互访问，也可以访问其他定名空间Pod，但其他定名空间不能访问test定名空间Pod。

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

复制代码

大概

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all-namespace
namespace: test
spec:
podSelector: {}
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
name: test # 指定本命名空间

复制代码

案例3：允许其他定名空间Pod访问指定应用

需求：允许其他定名空间访问test定名空间指定Pod

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

复制代码

案例4：同一个定名空间下应用之间限定访问

需求：将test定名空间中标签为run=web的pod隔离，只允许标签为 run=client1 的pod访问80端口

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

复制代码

案例5：只允许指定定名空间中的应用访问

需求：限定dev定名空间标签为 env=dev 的pod，

只允许 prod定名空间中的pod 访问
允许其他全部定名空间 app=client1标签pod访问

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:
name: prod
# 允许pod标签为app=client1的pod访问，所有命名空间
- from:
- namespaceSelector: {}
podSelector:
matchLabels:
app: client1

复制代码

六、k8s证书续签

K8s证书一般分为两套：K8s组件（apiserver）和 Etcd

如果按脚色来分，证书分为管理节点和工作节点。

管理节点：如果是kubeadm部署则自动天生，如果是二进制部署一般由cfssl大概openssl天生
工作节点：工作节点紧张是指kubelet和kube-proxy连接apiserver所需的客户端证书，kubelet证书由controller-manager组件自动颁发

注意：利用kubeadm方式部署，证书有效期为1年，证书过期会导致集群无法正常工作，日志会给出证书过期错误（x509: certificate has expired or is not yet valid）

证书利用在组件之间的通信

红线：K8s自建证书颁发机构（CA），需携带由它天生的客户端证书访问 apiserver

蓝色：Etcd自建证书颁发机构（CA），需携带由它天生的客户端证书访问etcd

命令：查察证书有效期

kubeadm certs check-expiration
openssl x509 -in -noout -dates
echo | openssl s_client -showcerts -connect 127.0.0.1:6443 -servername api 2>/dev/null | openssl x509 -noout -enddate

例如：

[root@k8s-master-1-71 pki]# kubeadm certs check-expiration
[check-expiration] Reading configuration from the cluster...
[check-expiration] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
# 根证书颁发的客户端证书（毕业证）
CERTIFICATE EXPIRES RESIDUAL TIME CERTIFICATE AUTHORITY EXTERNALLY MANAGED
admin.conf Mar 24, 2024 04:08 UTC 303d ca no
apiserver Mar 24, 2024 04:06 UTC 303d ca no
apiserver-etcd-client Mar 24, 2024 04:06 UTC 303d etcd-ca no
apiserver-kubelet-client Mar 24, 2024 04:06 UTC 303d ca no
controller-manager.conf Mar 24, 2024 04:07 UTC 303d ca no
etcd-healthcheck-client Feb 16, 2024 14:22 UTC 266d etcd-ca no
etcd-peer Feb 16, 2024 14:22 UTC 266d etcd-ca no
etcd-server Feb 16, 2024 14:22 UTC 266d etcd-ca no
front-proxy-client Mar 24, 2024 04:06 UTC 303d front-proxy-ca no
scheduler.conf Mar 24, 2024 04:07 UTC 303d ca no
# 根证书（大学、证书颁发机构）（根证书的有效期默认kubeadm设置为10年，一般情况下也不会变化）
CERTIFICATE AUTHORITY EXPIRES RESIDUAL TIME EXTERNALLY MANAGED
ca Feb 13, 2033 14:22 UTC 9y no
etcd-ca Feb 13, 2033 14:22 UTC 9y no
front-proxy-ca Feb 13, 2033 14:22 UTC 9y no
[root@k8s-master-1-71 ~]# cd /etc/kubernetes/pki/
[root@k8s-master-1-71 pki]# openssl x509 -in apiserver.crt -noout -dates
notBefore=Feb 16 14:22:31 2023 GMT
notAfter=Mar 24 04:06:51 2024 GMT
# 或者请求HTTPS查看服务续签变化
echo | openssl s_client -showcerts -connect 127.0.0.1:6443 -servername api 2>/dev/null | openssl x509 -noout -enddate
notAfter=Mar 24 04:06:51 2024 GMT

复制代码

增补：

在kubeadm部署集群之前，需举行续签的方法：修改kubeadm源码中证书的默认有效期；

在kubeadm部署集群之后，需举行续签的方法：

kubeadm certs 工具续签证书；
升级k8s集群版本，默认会再续签1年有效期

命令：续签全部证书

kubeadm certs renew all <--config=kubeadm.yaml> //可指定其它组件yaml文件

示例：kubeadm部署方式续签

# 查看证书有效期
[root@k8s-master-1-71 pki]# kubeadm certs check-expiration
# 备份
[root@k8s-master-1-71 ~]# cp -r /etc/kubernetes/ /etc/kubernetes.bak
[root@k8s-master-1-71 ~]# cp -r /var/lib/etcd/ /var/lib/etcd.bak
# 续签所有证书
[root@k8s-master-1-71 ~]# kubeadm certs renew all
# 重启生效证书
[root@k8s-master-1-71 ~]# kubectl delete pod kube-apiserver-k8s-master-1-71 kube-controller-manager-k8s-master-1-71 kube-scheduler-k8s-master-1-71 etcd-k8s-master-1-71 -n kube-system
pod "kube-apiserver-k8s-master-1-71" deleted
pod "kube-controller-manager-k8s-master-1-71" deleted
pod "kube-scheduler-k8s-master-1-71" deleted
pod "etcd-k8s-master-1-71" deleted
# kubectl使用新配置文件
cp -f /etc/kubernetes/admin.conf $HOME/.kube/config

复制代码

注：如果多master，其他证书和设置文件拷贝过去覆盖大概做上述同样操作

课后作业：

1、网络计谋

需求1：在test定名空间创建一个名为deny-all的网络计谋，拒绝本定名空间全部Pod的 Ingress和Egress流量

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

2、利用kube-bench工具查抄集群组件设置文件存在的题目与修复，并重启对应组件确保新设置见效。

小结

本篇为【Kubernetes CKS认证 Day1】的学习笔记，盼望这篇笔记可以让您开端相识到 CIS及Kube-beach的利用、相识Ingress设置证书、网络计谋等；课后另有扩展实践，不妨跟着我的笔记步伐亲身实践一下吧！

Tip：究竟两个人的智慧大于一个人的智慧，如果你不理解本章节的内容或需要相关笔记、视频，可私信小安，请不要害羞和回避，可以向他人讨教，花点时间直到你真正的理解。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

		自动登录	找回密码
密码			立即注册

CKS认证 | Day1 K8s集群部署与安全设置

马上注册，结交更多好友，享用更多功能，让你轻松玩转社区。

0 个回复

快速回复

楼主热帖

标签云

浏览过的版块