K8S
学习笔记

Kubernetes安全

# KUbernetes安全

# Kubernetes安全框架

K8S安全控制框架主要由下面3个阶段进行控制，每一个阶段都支持插件方式，通过API Server配置来启用插件。

Authentication（鉴权）
Authorization（授权）
Admission Control（准入控制）

客户端想要访问k8s集群API Server，一般需要证书，Token或者用户名+密码；如果Pod访问，需要ServiceAccount

# 认证、授权、准入控制

鉴权Authentication

K8s Apiserver提供三种客户端认证：
- HTTPS证书认证：基于CA证书签名的数字证书认证
- HTTP Token认证：通过一个Token来识别用户
- HTTP Base认证：用户名+密码的方式认证 （基本不采用）

授权Authorization

RBAC （Role-Based Access Control,基于角色的访问控制）：负责完成授权（Authorization工作）。

RBAC根据API请求属性，决定允许还是拒绝。

比较常见的授权维度：
- user：用户名
- group：用户分组
- 资源,例如Pod ConfigMaps Deployments Nodes Secrets Namespaces
- 资源操作方法： get,list,create,update,patch,watch,delete
- 命名空间
- API组

准入控制Admission Control

Admission Control实际上是一个准入控制器插件列表，发到API Server的请求都需要经过这个列表中的每个准入控制器插件来检查，检查不通过，则拒绝请求。

# 基于角色的权限访问控制：RBAC

RBAC 使⽤ rbac.authorization.k8s.io API Group 来实现授权决策，允许管理员通过 Kubernetes API 动态配置策略，要启⽤ RBAC ，需要在 apiserver 中添加参数 --authorization-mode=RBAC ，如果使⽤的 kubeadm 安装的集群，1.6 版本以上的都默认开启了 RBAC ，可以通过查看 Master 节点上 apiserver 的静态 Pod 定义⽂件：

$ cat /etc/kubernetes/manifests/kube-apiserver.yaml
...
- --authorization-mode=Node,RBAC
...

RBAC（Role-Based Access Control，基于角色的访问控制），允许Kubernetes API动态配置策略。

# 角色
- Role：授权特定命名空间的访问权限
- ClusterRole：授权所有命名空间的访问权限
# 角色绑定
- RoleBinding：将角色绑定到主体（即subject）
- ClusterRoleBinding：将集群角色绑定到主体
# 主体（subject）
- User：用户
- Group：用户组
- cluster-admin：K8s中默认管理员角色
- ServiceAccount：服务账号
# RoleBinding和ClusterRoleBinding
- RoleBinding 和 ClusterRoleBinding：⻆⾊绑定和集群⻆⾊绑定，简单来说就是把声明的 Subject 和我们的 Role 进⾏绑定的过程(给某个⽤户绑定上操作的权限)，⼆者的区别也是作⽤范围的区别：RoleBinding 只会影响到当前 namespace 下⾯的资源操作权限，⽽ ClusterRoleBinding 会影响到所有的 namespace。

# Role和RoleBinding使用

创建⼀个只能访问某个 namespace 的⽤户
我们来创建⼀个 User Account，只能访问 kube-system 这个命名空间：
- username: haima
- group: haimamax

# 第1步：创建⽤户凭证

这⾥我们来使⽤ OpenSSL 证书来创建⼀个 User，给⽤户 haima 创建⼀个私钥，命名成：haima.key：

[root@master ~]# openssl genrsa -out haima.key 2048
Generating RSA private key, 2048 bit long modulus
........+++
........................................................+++
e is 65537 (0x10001)

使⽤我们刚刚创建的私钥创建⼀个证书签名请求⽂件：haima.csr，要注意需要确保在 -subj 参数中指定⽤户名和组(CN表示⽤户名，O表示组)：

[root@master ~]# openssl req -new -key haima.key -out haima.csr -subj "/CN=haima/O=haimamax"

然后找到我们的 Kubernetes 集群的 CA ，我们使⽤的是 kubeadm 安装的集群， CA 相关证书位于 /etc/kubernetes/pki/ ⽬录下⾯，利⽤该⽬录下⾯的 ca.crt 和 ca.key 两个⽂件来批准上⾯的证书请求。

[root@master ~]# openssl x509 -req -in haima.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out haima.crt -days 500
Signature ok
subject=/CN=haima/O=haimamax
Getting CA Private Key

现在查看我们当前⽂件夹下⾯是否⽣成了⼀个证书⽂件：

[root@master ~]# ll
-rw-r--r-- 1 root root        997 Nov  7 21:27 haima.crt
-rw-r--r-- 1 root root        911 Nov  7 21:25 haima.csr
-rw-r--r-- 1 root root       1675 Nov  7 21:23 haima.key

现在我们可以使⽤刚刚创建的证书⽂件和私钥⽂件在集群中创建新的凭证和上下⽂(Context):

[root@master ~]# kubectl config set-credentials haima --client-certificate=haima.crt --client-key=haima.key 
User "haima" set.

我们可以看到⼀个⽤户 haima 创建了，然后为这个⽤户设置新的 Context:

[root@master ~]# kubectl config set-context haima-context --cluster=kubernetes --namespace=kube-system --user=haima
Context "haima-context" created.

到这⾥，我们的⽤户 haima 就已经创建成功了，现在我们使⽤当前的这个配置⽂件来操作 kubectl 命令的时候，应该会出现错误，因为我们还没有为该⽤户定义任何操作的权限呢：

[root@master ~]# kubectl get pods --context=haima-context 
Error from server (Forbidden): pods is forbidden: User "haima" cannot list resource "pods" in API group "" in the namespace "kube-system"

# 第2步：创建⻆⾊

⽤户创建完成后，接下来就需要给该⽤户添加操作权限，我们来定义⼀个 YAML ⽂件，创建⼀个允许⽤户操作 Deployment、Pod、ReplicaSets 的⻆⾊，如下定义：

[root@master work]# kubectl create role haima --namespace=kube-system --resource=pods,deployments,replicasets --verb=* --dry-run -o yaml > haima-role.yaml 
[root@master work]# cat haima-role.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  creationTimestamp: null
  name: haima
  namespace: kube-system
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - '*'
- apiGroups:
  - apps
  resources:
  - deployments
  - replicasets
  verbs:
  - '*'
  
注：
其中 Pod 属于 core 这个 API Group，在 YAML 中⽤空字符就可以，⽽ Deployment 属于 apps 这个API Group， ReplicaSets 属于 extensions 这个 API Group所以rules 下⾯的 apiGroups 就综合了这⼏个资源的 API Group：["", "extensions", "apps"]，其中 verbs 就是我们上⾯提到的可以对这些资源对象执⾏的操作，我们这⾥需要所有的操作⽅法，所以我们也可以使⽤['*']来代替。

然后创建这个 Role ：

[root@master work]# kubectl apply -f haima-role.yaml  
role.rbac.authorization.k8s.io/haima created

[root@master work]# kubectl get role -n kube-system | grep haima 
haima                                            2021-11-07T22:05:29Z

注：注意这⾥我们没有使⽤上⾯的 haimaxy-context 这个上下⽂了，因为⽊有权限

# 第3步：创建⻆⾊权限绑定

Role 创建完成了，但是很明显现在我们这个 Role 和我们的⽤户 haima 还没有任何关系，对吧？这⾥我就需要创建⼀个 RoleBinding 对象，在 kube-system 这个命名空间下⾯将上⾯的 haimaxy-role ⻆⾊和⽤户 haima 进⾏绑定

[root@master work]# kubectl create rolebinding haima-rolebinding --namespace=kube-system --role haima-role --user=haima --dry-run -o yaml > haima-rolebinding.yaml 
[root@master work]# cat  haima-rolebinding.yaml    
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  creationTimestamp: null
  name: haima-rolebinding
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: haima-role
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: haima

上⾯的 YAML ⽂件中我们看到了 subjects 关键字，这⾥就是我们上⾯提到的⽤来尝试操作集群的对象，这⾥对应上⾯的 User 帐号 haimaxy，使⽤ kubectl 创建上⾯的资源对象：

[root@master work]# kubectl apply -f haima-rolebinding.yaml  
rolebinding.rbac.authorization.k8s.io/haima-rolebinding created

[root@master work]# kubectl get rolebindings -n kube-system  | grep haima 
haima-rolebinding                                   Role/haima-role                                       21s

# 第4步：测试

现在我们应该可以上⾯的 haimaxy-context 上下⽂来操作集群了：

[root@master work]# kubectl get pods --context=haima-context 
Error from server (Forbidden): pods is forbidden: User "haima" cannot list resource "pods" in API group "" in the namespace "kube-system": RBAC: role.rbac.authorization.k8s.io "haima-role" not found

我们可以看到我们使⽤ kubectl 的使⽤并没有指定 namespace 了，这是因为我们已经为该⽤户分配了权限了，如果我们在后⾯加上⼀个 -n default

[root@master work]# kubectl get pods --context=haima-context -n default                                        
Error from server (Forbidden): pods is forbidden: User "haima" cannot list resource "pods" in API group "" in the namespace "default"

注：
是符合我们预期的吧？因为该⽤户并没有 default 这个命名空间的操作权限

创建⼀个只能访问某个 namespace 的ServiceAccount
上⾯我们创建了⼀个只能访问某个命名空间下⾯的普通⽤户，我们前⾯也提到过 subjects 下⾯还有⼀直类型的主题资源：ServiceAccount，现在我们来创建⼀个集群内部的⽤户只能操作 kube-system 这个命名空间下⾯的 pods 和 deployments，⾸先来创建⼀个 ServiceAccount 对象：

[root@master work]# kubectl create sa haima-sa -n kube-system  
serviceaccount/haima-sa created

然后新建⼀个 Role 对象：

[root@master work]# kubectl create role haima-sa-role --namespace=kube-system --resource=pod,deployments --verb=get,watch,list,create,update,patch,delete  --dry-run -o yaml > haima-sa-role.yaml

[root@master work]# vi haima-sa-role.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  creationTimestamp: null
  name: haima-sa-role
  namespace: kube-system
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - watch
  - list
- apiGroups:
  - apps
  resources:
  - deployments
  verbs:
  - get
  - watch
  - list
  - create
  - update
  - patch
  - delete

可以看到我们这⾥定义的⻆⾊没有创建、删除、更新 Pod 的权限，待会我们可以重点测试⼀下，创建该 Role 对象：

[root@master work]# kubectl apply -f haima-sa-role.yaml 
role.rbac.authorization.k8s.io/haima-sa-role created

[root@master work]# kubectl get role -n kube-system | grep sa
haimaxy-sa-role                                  2021-11-07T20:56:00Z

然后创建⼀个 RoleBinding 对象，将上⾯的 haimaxy-sa 和⻆⾊ haimaxy-sa-role 进⾏绑定：

[root@master work]# kubectl create rolebinding haima-sa-rolebinding --namespace=kube-system --role=haima-sa-role --serviceaccount kube-system:haima-sa --dry-run -o yaml > haima-sa-rolebinding.yaml 

[root@master work]# cat  haima-sa-rolebinding.yaml  
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  creationTimestamp: null
  name: haima-sa-rolebinding
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: haima-sa-role
subjects:
- kind: ServiceAccount
  name: haima-sa
  namespace: kube-system

添加这个资源对象：

[root@master work]# kubectl apply -f  haima-rolebinding.yaml  
rolebinding.rbac.authorization.k8s.io/haima-sa-rolebinding created

[root@master work]# kubectl get rolebinding -n kube-system | grep sa
haima-sa-rolebinding                                Role/haima-sa-role                                    26s

然后我们怎么去验证这个 ServiceAccount 呢？我们前⾯的课程中是不是提到过⼀个 ServiceAccount 会⽣成⼀个 Secret 对象和它进⾏映射，这个 Secret ⾥⾯包含⼀个 token，我们可以利⽤这个 token 去登录 Dashboard，然后我们就可以在 Dashboard 中来验证我们的功能是否符合预期了：

[root@master work]# kubectl get secrets -n kube-system | grep haima-sa
haima-sa-token-k26k7                             kubernetes.io/service-account-token   3      20m

[root@master work]#  kubectl get secret haima-sa-token-k26k7 -o jsonpath={.data.token} -n kube-system |base64 -d 
eyJhbGciOiJSUzI1NiIsImtpZCI6IjNzT0lqNW1qTjBCcjBQcTRseTdPc0ZoWDd1T3hXazRtWHk1TGI1alp0QU0ifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJoYWltYS1zYS10b2tlbi1rMjZrNyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJoYWltYS1zYSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6Ijc1ZDc4Mzc3LTY4MGItNDhiNS04YTM1LWEzY2UxODhlZTJhNyIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDprdWJlLXN5c3RlbTpoYWltYS1zYSJ9.ubKdejm1cCRcEcNLUCUrXCkD6BahSnyEhxszyfBSol6FDhBqRiz2G7IuIgF4EGlvfmnFTmBsKD8iyDfCAwfGMqg_crwFc8DFPyACLjjPVAI-zLdQhlsfnQrulFVCftbVA3HjQ3qF04Uu59jPm7Hm4ap-1SRHSzxnqGWLHQpwJpSdh8lk1C4uRWyJLXQz0_2prQH5roFySmvKRvVujcEqsv_Meu9h9HoSNQNN1oyhfx9kZLCviMALeLxWB8WkhfZzKDVN0bag2g8i7Q-i_76I19C0dd-F-wueQOjA86R9x7RcuakqET_5pkl31bxfA6xUOY8p25s3koP5RjshIskclA[root@master work]#

使⽤这⾥的 token 去 Dashboard ⻚⾯进⾏登录：

我们可以看到可以访问pod列表了，但是也会有⼀些其他额外的提示：events is forbidden: User “system:serviceaccount:kube-system:haimaxy-sa” cannot list events in the namespace “kube-system”，这是因为当前登录⽤只被授权了访问 pod 和 deployment 的权限.
创建⼀个可以访问所有 namespace 的ServiceAccount
如果我们现在创建⼀个新的 ServiceAccount，需要他操作的权限作⽤于所有的 namespace，这个时候我们就需要使⽤到 ClusterRole 和 ClusterRoleBinding 这两种资源对象了。同样，⾸先新建⼀个 ServiceAcount 对象：

[root@master work]# cat haima-sa2.yaml  
apiVersion: v1
kind: ServiceAccount
metadata:
  name: haima-sa2
  namespace: kube-system
  
[root@master work]# kubectl apply -f haima-sa2.yaml  
serviceaccount/haimaxy-sa2 created

然后创建⼀个 ClusterRoleBinding 对象:

[root@master work]# cat clusterrolebinding.yaml 
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: haima-sa2-clusterrolebinding
subjects:
- kind: ServiceAccount
  name: haima-sa2
  namespace: kube-system
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

从上⾯我们可以看到我们没有为这个资源对象声明 namespace，因为这是⼀个 ClusterRoleBinding 资源对象，是作⽤于整个集群的，我们也没有单独新建⼀个 ClusterRole 对象，⽽是使⽤的 cluster-admin 这个对象，这是 Kubernetes 集群内置的 ClusterRole 对象，我们可以使⽤ kubectl get clusterrole 和 kubectl get clusterrolebinding 查看系统内置的⼀些集群⻆⾊和集群⻆⾊绑定，这⾥我们使⽤的 cluster-admin 这个集群⻆⾊是拥有最⾼权限的集群⻆⾊，所以⼀般需要谨慎使⽤该集群⻆⾊。

创建上⾯集群⻆⾊绑定资源对象，创建完成后同样使⽤ ServiceAccount 对应的 token 去登录 Dashboard 验证下：

[root@master work]# kubectl apply -f clusterrolebinding.yaml            
clusterrolebinding.rbac.authorization.k8s.io/haima-sa2-clusterrolebinding created

[root@master work]# kubectl get secrets -n kube-system | grep haima
haima-sa-token-khljg                             kubernetes.io/service-account-token   3      14m

# 网络策略概述

网络策略（Network Policy），用于限制Pod出入流量，提供Pod级别和Nameaspace级别的网络访问控制。flannel不支持，calico是支持的。

Pod 可以通信的 Pod 是通过如下三个标识符的组合来辩识的：
- 其他被允许的 Pods（例外：Pod 无法阻塞对自身的访问）
- 被允许的名字空间
- IP 组块（例外：与 Pod 运行所在的节点的通信总是被允许的，无论 Pod 或节点的 IP 地址）

# 一些应用场景：

应用程序的访问控制。例如微服务A允许访问微服务B，微服务C不能访问微服务A
开发环境命名空间不能访问测试环境命名空间Pod
当Pod暴露到外部时，需要做Pod白名单
多租户网络环境隔离

# Pod网络入口方向隔离：

基于Pod级网络隔离：只允许特定对象访问Pod（使用标签定义），允许白名单上的IP地址或者IP段访问Pod。
基于Namespace级网络隔离：多个命名空间，A和B命名空间Pod完全隔离

# Pod网络出口方向隔离:

拒绝某一个Namespace上所有的Pod访问外部
基于目的IP的网络隔离：只允许Pod访问白名单上的IP地址或者IP段
基于目标端的网络隔离：只允许Pod访问白名单上的端口

# NetworkPolicy的选项

podSelector：目标Pod，根据标签选择，每个 NetworkPolicy 都包括一个 podSelector，它对该策略所适用的一组 Pod 进行选择。
policyTypes：策略类型，每个 NetworkPolicy 都包含一个 policyTypes 列表，其中包含 Ingress 或 Egress 或两者兼具。指定策略用于入站，出站流量。如果 NetworkPolicy 未指定 policyTypes 则默认情况下始终设置 Ingress；如果 NetworkPolicy 有任何出口规则的话则设置 Egress
Ingress：每个 NetworkPolicy 可包含一个 ingress 规则的白名单列表。每个规则都允许同时匹配 from 和 ports 部分的流量。
Egress: 每个 NetworkPolicy 可包含一个 egress 规则的白名单列表。每个规则都允许匹配 to 和 port 部分的流量。该示例策略包含一条规则，该规则将指定端口上的流量匹配到 10.0.0.0/24 中的任何目的地。

[root@master work]# vim networkpolicy.yaml 
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:					#标签选择器
    matchLabels:			
      role: db					#匹配role等于db的
  policyTypes:					#策略的类型
  - Ingress						#Ingress类型  指定入口的流量
  - Egress
  ingress:						#指定入口流量
  - from:						#入口流量来自哪里
    - ipBlock:				
        cidr: 172.17.0.0/16		#指定该ip的段16掩码是可以访问我
        except:
        - 172.17.1.0/24			#除了该网段24掩码的不能访问
    - namespaceSelector:		#命名空间标签选择器
        matchLabels:
          project: myproject	#myproject的标签
    - podSelector:				#Pod标签选择 
        matchLabels:
          role: frontend		#role的标签的Pod可以访问
    ports:						#port的协议以及端口
    - protocol: TCP	
      port: 6379
  egress:						#限制出口流量
  - to:							
    - ipBlock:	
        cidr: 10.0.0.0/24		#可以访问该网段
    ports:
    - protocol: TCP				#可以访问该网段的端口
      port: 5978

# 对项目Pod出入流量控制：隔离

将default命名空间携带app=web标签的Pod隔离，只允许default命名空间携带run=client1标签的Pod访问80端口
准备测试环境（做好ingress）

[root@master ~]# kubectl create deployment web --image=nginx 
[root@master ~]# kubectl run client1 --image=busybox --sleep 36000
[root@master ~]# kubectl run client2 --image=busybox --sleep 36000

[root@master ~]# kubectl get pods 
NAME                  READY   STATUS    RESTARTS   AGE
client1               1/1     Running   0          53m
client2               1/1     Running   0          53m
web-96d5df5c8-w2vvf   1/1     Running   0          53m

先不做网络策略尝试

[root@master ~]# kubectl get pods -o wide 
NAME                  READY   STATUS    RESTARTS   AGE   IP               NODE   NOMINATED NODE   READINESS GATES
client1               1/1     Running   0          55m   10.244.167.130   node   <none>           <none>
client2               1/1     Running   0          55m   10.244.167.131   node   <none>           <none>
web-96d5df5c8-w2vvf   1/1     Running   0          55m   10.244.167.129   node   <none>           <none>

可以发现没有网络策略是可以ping可以拉取

[root@master ~]# kubectl exec -it  client1  -- sh 
/ # ping 10.244.167.129
PING 10.244.167.129 (10.244.167.129): 56 data bytes
64 bytes from 10.244.167.129: seq=0 ttl=63 time=0.088 ms
64 bytes from 10.244.167.129: seq=1 ttl=63 time=0.073 ms
^C
--- 10.244.167.129 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.073/0.080/0.088 ms


/ # wget 10.244.167.129
Connecting to 10.244.167.129 (10.244.167.129:80)
saving to 'index.html'
index.html           100% |**********************************************************************************************************|   615  0:00:00 ETA
'index.html' saved

创建一个将app=web的pod隔离，run=client1的可以访问

[root@master ~]# cat networkpolicy.yaml 
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:			#隔离app=web的pods
      app: web 
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:			#只允许run=client1的访问tcp的80端口
        matchLabels: 
          run: client1
    ports: 
    - protocol: TCP
      port: 80

测试网络策略是否生效
此时会发现networkpolicy的入口流量被阻断，无法ping通，但是可以访问80端口

[root@master ~]# kubectl apply -f networkpolicy.yaml 
networkpolicy.networking.k8s.io/test-network-policy created
[root@master ~]# kubectl exec -it  client1  -- sh 
/ # ping 10.244.167.129
PING 10.244.167.129 (10.244.167.129): 56 data bytes
^C
--- 10.244.167.129 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss

/ # wget 10.244.167.129
Connecting to 10.244.167.129 (10.244.167.129:80)
saving to 'index.html'
index.html           100% |**********************************************************************************************************|   615  0:00:00 ETA
'index.html' saved
/ #

用client2去测试，发现都被阻断了

[root@master ~]# kubectl exec -it  client2  -- sh 
/ # ping 10.244.167.129
PING 10.244.167.129 (10.244.167.129): 56 data bytes
^C
--- 10.244.167.129 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
/ # wget 10.244.167.129
Connecting to 10.244.167.129 (10.244.167.129:80)
^C
/ #

# 对项目Pod出入流量控制：单向访问

default命名空间的所有Pod可以互相访问，也可以访问其他命名空间的Pod，但是其他命名空间的Pod不能访问default的Pod。
podSelector：{} ：如果未配置，默认所有Pod
from.podSelector：{} ：如果未配置，默认不允许

[root@master ~]# cat networkpolicy.yaml 
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: np2 
  namespace: default
spec:
  podSelector: {}  #针对当前命名空间所有
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector: {}  #所有默认不允许
    
    
[root@master ~]# kubectl apply -f networkpolicy.yaml 
networkpolicy.networking.k8s.io/np2 created

使用之前的三个默认命名空间的Pod

[root@master ~]# kubectl get pods 
NAME                  READY   STATUS    RESTARTS   AGE
client1               1/1     Running   0          82m
client2               1/1     Running   0          82m
web-96d5df5c8-w2vvf   1/1     Running   0          82m

再创建一个kube-system的client3做实验

[root@master ~]# kubectl run client3 --image=busybox --namespace=kube-system -- sleep 36000
pod/client3 created

[root@master ~]# kubectl get pods -n kube-system | grep client3 
client3                                    1/1     Running   0          92s

查看当前default的Pods和kube-system的Pods

[root@master ~]# kubectl get pods -n kube-system  -o wide 
NAME                                       READY   STATUS    RESTARTS   AGE     IP               NODE     NOMINATED NODE   READINESS GATES
···
coredns-7f89b7bc75-qf8dg                   1/1     Running   0          154m    10.244.219.65    master   <none>           <none>
[root@master ~]# kubectl get pods   -o wide 
NAME                  READY   STATUS    RESTARTS   AGE   IP               NODE   NOMINATED NODE   READINESS GATES
client1               1/1     Running   0          83m   10.244.167.130   node   <none>           <none>
client2               1/1     Running   0          83m   10.244.167.131   node   <none>           <none>
web-96d5df5c8-w2vvf   1/1     Running   0          84m   10.244.167.129   node   <none>           <none>

使用clinet1去测试，去ping两个命名空间的pods，发现成功ping通

[root@master ~]# kubectl exec -it client1 -- sh 
/ # ping 10.244.219.65
PING 10.244.219.65 (10.244.219.65): 56 data bytes
64 bytes from 10.244.219.65: seq=0 ttl=62 time=0.525 ms
^C
--- 10.244.219.65 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.525/0.525/0.525 ms
/ # ping 10.244.167.129
PING 10.244.167.129 (10.244.167.129): 56 data bytes
64 bytes from 10.244.167.129: seq=0 ttl=63 time=0.100 ms
^C
--- 10.244.167.129 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.100/0.100/0.100 ms
/ #

使用kube-system命名空间的client3测试
可以看出直接被拒绝访问

[root@master ~]# kubectl exec -it client3 -n kube-system -- sh 
/ # ping 10.244.167.130
PING 10.244.167.130 (10.244.167.130): 56 data bytes
^C
--- 10.244.167.130 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
/ #

上次更新: 2023/11/28, 22:03:59

← Kubernetes存储 Kubernetes集群维护→

Kubernetes安全

# KUbernetes安全