Cilium Network Policy
一、第三层配置示例
1. 基于Label的策略
使用busybox启动三个pod:box-a,box-b,box-c,测试a->b,c->b联通性
入口策略
配置基于label的策略:只允许a->b
apiVersion: "cilium.io/v2" kind: CiliumNetworkPolicy metadata: name: "a-to-b-allow" spec: endpointSelector: matchLabels: app: box-b ingress: - fromEndpoints: - matchLabels: app: box-a
以上配置使用了简单的入口规则来允许带有标签
app=box-a的endpoint到带有标签app=box-b的endpoint的通信,其他的默认拒绝。即:b只允许a的流量通过,其他拒绝
配置允许所有的endpoints到
app=box-b的通信
apiVersion: "cilium.io/v2" kind: CiliumNetworkPolicy metadata: name: "all-to-b-allow" spec: endpointSelector: matchLabels: app: box-b ingress: - fromEndpoints: - {}
配置拒绝所有的endpoints到
app=box-b的通信
apiVersion: "cilium.io/v2" kind: CiliumNetworkPolicy metadata: name: "all-to-b-deny" spec: endpointSelector: matchLabels: app: box-b ingress: - {}
出口策略
配置基于label的策略,b只能到a
apiVersion: "cilium.io/v2" kind: CiliumNetworkPolicy metadata: name: "a-from-b-allow" spec: endpointSelector: matchLabels: app: box-b egress: - toEndpoints: - matchLabels: app: box-a
配置允许
app=box-b到所有的endpoints的通信
apiVersion: "cilium.io/v2" kind: CiliumNetworkPolicy metadata: name: "a-from-b-allow" spec: endpointSelector: matchLabels: app: box-b egress: - toEndpoints: - {}
配置拒绝
app=box-b到所有的endpoints的通信
apiVersion: "cilium.io/v2" kind: CiliumNetworkPolicy metadata: name: "a-from-b-allow" spec: endpointSelector: matchLabels: app: box-b egress: - {}
2. 基于Service的策略
配置允许
app=httpbox-b的endpoint到default命名空间中的所有的
serviceName=httpbox-a的endpoint的通信
apiVersion: "cilium.io/v2" kind: CiliumNetworkPolicy metadata: name: "svc-a-from-b-allow" spec: endpointSelector: matchLabels: app: httpbox-b egress: - toServices: - k8sService: serviceName: httpbox-a namespace: default
*配置之后没有达到预期效果,反而是httpbox-b到其他所有的通信都被拒绝了
3. 基于Entities的策略
Cilium基于entities的策略由
fromEntities和toEntities来定义;fromEntities用于描述那些类型的实体可以访问所选择的endpoint;toEntities用于描述所选择的endpoint可以访问的那些类型的实体。Cilium定义了下列实体类型:
- host:主机实体类型包括本地主机,还包括在本地主机上以
host networking模式运行的所有容器;- remote-node:除本地主机以外的集群中的其他主机。还包括其他节点上以
host networking模式运行的所有容器;- cluster:cluster是本地集群内所有
network endpoints的逻辑组。这包括本地集群的所有Cilium-managed endpoints、本地集群中的unmanaged endpoints以及 host, remote-node和init类型;- init:init类型包含引导阶段中尚未解析其安全身份的所有endpoints,通常只在非Kubernetes环境中观察到;
- health:运行状况健康的endpoints,用于检查群集连接状况。Cilium管理的每个节点都承载一个
health endpoints;- unmanaged:unmanaged表示不由Cilium管理的endpoints。Unmanaged endpoints被视为cluster的一部分,并包含在cluster实体中。
- world:world实体对应于cluster之外的所有endpoints,允许world实体等同于允许CIDR0.0.0.0/0。允许和拒绝world模式的另一种实现方式是基于DNS或CIDR的细粒度策略。
- all:所有已知cluster以及world的组合,并将所有通信列入白名单。
配置允许
app=httpbox-a的endpoint到本地主机的通信
apiVersion: "cilium.io/v2" kind: CiliumNetworkPolicy metadata: name: "a-to-host" spec: endpointSelector: matchLabels: app: httpbox-a egress: - toEntities: - host
配置允许
app=httpbox-a的endpoint只到集群中其他节点,不到本地主机的通信
apiVersion: "cilium.io/v2" kind: CiliumNetworkPolicy metadata: name: "a-to-remote" spec: endpointSelector: matchLabels: app: httpbox-a egress: - toEntities: - remote-node
配置只允许本地主机到
app=httpbox-a的endpoint的通信
apiVersion: "cilium.io/v2" kind: CiliumNetworkPolicy metadata: name: "a-from-host" spec: endpointSelector: matchLabels: app: httpbox-a ingress: - fromEntities: - host
4. 基于IP/CIDR的策略
CIDR策略用于定义往返于不受Cilium管理的endpoints的策略,因此没有与之关联的标签。这些通常是运行在特定子网中的外部服务,VM或金属机。CIDR策略还可以用于限制对外部服务的访问,例如,将外部访问限制为特定的IP范围。CIDR策略可以在入口或出口应用。
如果Cilium无法将源或目的地映射到由labels定义的endpoints的身份,则CIDR适用于CIDR。例如,CIDR规则将适用于连接一侧为:
- 集群外的网络端点
- 运行Pod的主机网络名称空间。
- 在群集前缀内,但Cilium不提供IP网络。
相反,CIDR规则不适用于连接的两端都由Cilium管理或使用属于群集中某个节点的IP(包括主机联网Pod)的流量。如上所述,可以使用基于labels, services或者entities的策略来允许该流量。
Cilium CIDR定义了以下几种类型的策略
入口策略
fromCIDR:允许与
endpointSelector选择的所有endpoints进行通信的源prefixes/CIDR列表。- fromCIDRSet:允许与
endpointSelector所选择的所有endpoints进行通信的源prefixes/CIDR列表,但是这个列表中排除的部分子网是被禁止的。出口策略
toCIDR:允许与
endpointSelector选择的endpoints进行通信的目标prefixes/CIDR列表 。需要注意的是,由一个fromEndpoints选择的endpoints将自动允许回复给相应的目标endpoints。- toCIDRSet:允许与
endpointSelector所选择的所有endpoints进行通信的目标prefixes/CIDR列表,但是这个列表中排除的部分子网是被禁止的。
定义一个允许到外部CIDR网段的通信
apiVersion: "cilium.io/v2" kind: CiliumNetworkPolicy metadata: name: "a-to-cidr" spec: endpointSelector: matchLabels: app: httpbox-a egress: - toCIDR: - 114.114.114.114/32 - toCIDRSet: - cidr: 223.0.0.0/8 except: - 223.6.0.0/16
该策略定义了标签
app=httpbox-a所选择的endpoints只能访问114.114.114.114/32这个IP,和223.0.0.0/8中除了223.6.0.0/16这个子网的其他IP地址。
配置CIDR策略前
策略未配置前
策略配置生效后
5. 基于DNS的策略
DNS策略用于为不受Cilium管理但具有DNS可查询域名的endpoints定义第3层策略。Cilium允许从DNS响应中提供的IP地址,其方式类似于基于CIDR的策略中的IP 。当远程IP可能更改或事先不知道时,或者DNS更方便时,它是一种替代方案。要对DNS请求本身实施策略,需要使用第七层的策略。
*需要注意的是,基于DNS的规则旨在用于外部连接,其行为类似于基于CIDR的规则。
定义一个使用DNS的策略,httpbox-a只能访问百度的域名和IP
apiVersion: "cilium.io/v2" kind: CiliumNetworkPolicy metadata: name: "a-to-baidu-dns" spec: endpointSelector: matchLabels: app: httpbox-a egress: - toEndpoints: - matchLabels: "k8s:io.kubernetes.pod.namespace": kube-system "k8s:k8s-app": kube-dns toPorts: - ports: - port: "53" protocol: ANY rules: dns: - matchPattern: "*" - toFQDNs: - matchName: "www.baidu.com"
二、第四层配置示例
除了第3层策略外,还可以单独指定第4层的策略,它限制了endpoints使用特定协议在特定端口上收发数据包的能力。如果没有为endpoints指定第4层策略,则允许其在所有第4层端口和协议(包括ICMP)上发送和接收。如果指定了任何第4层策略,则ICMP将被阻止,除非它与该策略允许的连接相关。应用服务端口映射后,第4层策略将应用于端口。
1.Port
配置一个简单的示例,httpbox-b对其他的所有服务只开启8000端口
apiVersion: "cilium.io/v2" kind: CiliumNetworkPolicy metadata: name: "b-from-all-port" spec: endpointSelector: matchLabels: app: httpbox-b ingress: - toPorts: - ports: - port: "8000" protocol: TCP
策略未配置前
策略配置后,可以看到ICMP报文已经被禁止
与labels相关的4层配置,该策略定义了标签
app=httpbox-c所选择的endpoints才能访问httpbox-b的相应端口
apiVersion: "cilium.io/v2" kind: CiliumNetworkPolicy metadata: name: "b-from-c-port" spec: endpointSelector: matchLabels: app: httpbox-b ingress: - fromEndpoints: - matchLabels: app: httpbox-c toPorts: - ports: - port: "8000" protocol: TCP
三、第七层配置示例
第7层策略规则嵌入第4层示例规则中,并且可以为入口和出口指定。
L7Rules结构是是一个包含协议特定字段枚举的基本类型。目前第七层策略支持的有HTTP\DNS\Kafka(测试阶段)。
需要注意的是当前每个endpoints最多支持40个端口在第七层策略上,以及不支持节点选择的策略。
1.HTTP
使用http类型的策略有以下字段可以选择:
- Path:与请求路径匹配的扩展POSIX正则表达式;
- Method:请求的方法,如
GET,POST,PUT,PATCH,DELETE等;- Host:与请求的主机header匹配的正则表达式,例如:
foo.com;- Headers:请求中存在的http header列表。
配置示例:允许GET /_cat
apiVersion: "cilium.io/v2" kind: CiliumNetworkPolicy metadata: name: "es-from-get" spec: endpointSelector: matchLabels: app: elasticsearch release: ess ingress: - toCIDR: - 10.11.92.33/32 toPorts: - ports: - port: "9200" protocol: TCP rules: http: - method: "GET" path: "/_cat"
2.DNS
DNS策略可以通过以下方式应用:
- matchName:允许查询
matchName完全匹配的域。多个不同的名称可能会包含在单独的matchName条目中,并且允许查询与matchName匹配的域;- matchPattern:允许查询匹配
matchPattern模式中的域,并考虑通配符。模式中域名允许由a-z,0-9.和-这些字符组成;注意事项:尽管可以在不使用任何其他第3层规则的情况下应用第7层DNS策略,但是第7层规则的存在将阻止其他的流量。
配置一个示例:httpbox-a只能访问baidu.com以及*.baidu.com
apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: "a-to-baidu-only-dns" spec: endpointSelector: matchLabels: app: httpbox-a egress: - toEndpoints: - matchLabels: "k8s:io.kubernetes.pod.namespace": kube-system "k8s:k8s-app": kube-dns toPorts: - ports: - port: "53" protocol: ANY rules: dns: - matchName: "baidu.com" - matchPattern: "*.baidu.com" - toFQDNs: - matchName: "baidu.com" - matchPattern: "*.baidu.com"
3.Kafka(测试阶段)
Kafka策略可以定义的字段为:
- Role:支持两种类型的角色,produce和consume;
- APIKey:与请求的key匹配的不区分大小写的字符串,例如
produce,fetch,createtopic,deletetopic,该字段与Role不兼容;- APIVersion:允许的Kafka api版本,为空则允许所有版本;
- ClientID:请求中提供的客户端标识符;
- Topic:息中包含的主题名称。
apiVersion: "cilium.io/v2" kind: CiliumNetworkPolicy metadata: name: "rule1" spec: endpointSelector: matchLabels: app: kafka ingress: - fromEndpoints: - matchLabels: app: empire-hq toPorts: - ports: - port: "9092" protocol: TCP rules: kafka: - role: "produce" topic: "deathstar-plans" - role: "produce" topic: "empire-announce"
- Policy-Driven Mobile Ad hoc Network Management
- at android.os.StrictMode$AndroidBlockGuardPolicy.onNetwork
- Android用HTTP下载报错“android.os.StrictMode$AndroidBlockGuardPolicy.onNetwork”
- 通读AFN③--HTTPS访问控制(AFSecurityPolicy),Reachability(AFNetworkReachabilityManager)
- [VMware KA] VMware Network Security Policy
- 论文笔记——N2N Learning: Network to Network Compression via Policy Gradient Reinforcement Learning
- android错误:at android.os.StrictMode$AndroidBlockGuardPolicy.onNetwork
- Android9.0 使用http请求报错communication to not permitted by network security policy
- Ubuntu出现System policy prevents modification of network settings for all users该怎么解决
- at android.os.StrictMode$AndroidBlockGuardPolicy.onNetwork(错误
- not permitted by network security policy
- Android:StrictMode VmPolicy violation with POLICY_DEATH; android.os.NetworkOnMainThreadException
- kubernetes networkpolicy
- at android.os.StrictMode$AndroidBlockGuardPolicy.onNetwork(错误
- Android版本28使用http请求报错not permitted by network security policy
- Android中关于:at android.os.StrictMode$AndroidBlockGuardPolicy.onNetwork(StrictMode.java:1099) 的问题
- 通读AFN③--HTTPS访问控制(AFSecurityPolicy),Reachability(AFNetworkReachabilityManager)
- at android.os.StrictMode$AndroidBlockGuardPolicy.onNetwork(错误
- Android版本28使用http请求报错not permitted by network security policy