k8s-使用Network Policies实现网络隔离

于 2024-08-29 15:31:27 发布
阅读量1.2k 收藏 31
点赞数 16
文章标签： kubernetes 网络 容器
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/dsgdauigfs/article/details/141671898
版权

一、需求

Kubernetes 的命名空间主要用于组织和隔离资源，但默认情况下，不同命名空间中的 Pod 之间是可以相互通信的。为了实现更严格的网络隔离，同一套k8s需要根据不同的命名空间进行网络环境隔离，例如开发（dev01）测试（test01）环境。Network Policies 是 Kubernetes 提供的一种机制，用于控制 Pod 间的网络流量。你可以为每个命名空间定义 Network Policies 来限制 Pod 之间的通信。

二、相关解释

  • spec.PodSelector

它是pod选择器，基于标签选择与Network Policy处于同一namespace下的pod，如果pod被选中，则对其应用Network Policy中定义的规则。此为可选字段，当没有此字段时，表示选中所有pod。

  • spec.PolicyTypes

Network Policy定义的规则可以分成两种，一种是入pod的Ingress规则，一种是出pod的Egress规则。本字段可以看作是一个开关，如果其中包含Ingress，则Ingress部分定义的规则生效，如果是Egress则Egress部分定义的规则生效，如果都包含则全部生效。当然此字段也可选，如果没有指定的话，则默认Ingress生效，如果Egress部分有定义的话，Egress才生效。怎么理解这句话，下文会提到，没有明确定义Ingress、Egress部分，它也是一种规则，默认规则而非没有规则。

  • spec.ingress与spec.egress

spec.ingress 和 spec.egress 字段分别用于定义允许进入 Pod 的流量规则和允许离开 Pod 的流量规则。下面详细解释这两个字段的结构和包含的子项。

spec.ingress 结构

spec:
  ingress:
  - from:
    - podSelector:
        matchLabels: {} # 选择具有特定标签的 Pod
    - namespaceSelector:
        matchLabels: {} # 选择具有特定标签的命名空间
    - ipBlock:
        cidr: 0.0.0.0/0 # CIDR 地址范围
        except:
        - 10.0.0.0/8 # 排除的 CIDR 地址范围
  - ports:
    - protocol: TCP # 协议类型
      port: 80 # 具体端口
      endPort: 8080 # 如果是端口范围，则需要指定结束端口

spec.egress 结构

spec:
  egress:
  - to:
    - podSelector:
        matchLabels: {} # 选择具有特定标签的 Pod
    - namespaceSelector:
        matchLabels: {} # 选择具有特定标签的命名空间
    - ipBlock:
        cidr: 0.0.0.0/0 # CIDR 地址范围
        except:
        - 10.0.0.0/8 # 排除的 CIDR 地址范围
  - ports:
    - protocol: TCP # 协议类型
      port: 80 # 具体端口
      endPort: 8080 # 如果是端口范围，则需要指定结束端口

示例

假设你有一个 NetworkPolicy，它允许 Pod 接收来自 CIDR 地址范围 192.168.1.0/24 的流量，并允许 Pod 发送流量到 CIDR 地址范围 10.0.0.0/8，同时只允许通过 TCP 协议的端口 80 和 443 进行通信。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-traffic
  namespace: my-namespace
spec:
  podSelector: {}
  ingress:
  - from:
    - ipBlock:
        cidr: 192.168.1.0/24
  - ports:
    - protocol: TCP
      port: 80
    - protocol: TCP
      port: 443
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/8
  - ports:
    - protocol: TCP
      port: 80
    - protocol: TCP
      port: 443
  policyTypes:
  - Ingress
  - Egress

注意事项

  • 适用性: 该 NetworkPolicy 适用于 my-namespace 命名空间中的所有 Pod。

  • 流量控制: 控制了 Ingress 和 Egress 流量。

  • CIDR 地址范围: 192.168.1.0/24 和 10.0.0.0/8 通常用于私有网络。

  • 端口控制: 只允许通过 TCP 协议的端口 80 和 443 进行通信。

三、测试规划

1、创建命名空间

2、创建pod和nodeport

3、应用策略之前测试

4、创建网络策略1-pod隔离

5、创建网络策略2-命名空间隔离

6、创建网络策略3-业务命名空间隔离

四、具体实施

1、创建命名空间

创建测试使用的3个命名空间sub1，sub2，sub3。

如果后面的网络策略使用到namespaceSelector，在创建命名空间时需要带label，也可在需要时手动添加label。

kubectl create ns sub1 --labels ns=sub1
kubectl create ns sub2 --labels ns=sub2
kubectl create ns sub3 --labels ns=sub2

  如果使用的是私有仓库，注意ns要创建docker-secret。

kubectl create secret docker-registry my-registry-secret --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD -n namespace

2、创建pod和nodeport

2.1、sub1创建sub1-pod1和sub1-pod1-nodeport，sub1-pod2；　

2.2、sub2创建sub2-pod1和sub2-pod1-nodeport，sub2-pod2；　

2.3、sub3创建sub3-pod1；

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sub1-pod1
  namespace: sub1
spec:
  selector:
    matchLabels:
      app: sub1pod1
  replicas: 1
  template:
    metadata:
      labels:
        app: sub1pod1
    spec:
      containers:
      - name: my-test01-01
        image: swr.cn-east-3.myhuaweicloud.com/k8s-imgs/account-platform-admin:dev01-084e7d9
        imagePullPolicy: IfNotPresent
      imagePullSecrets:
      - name: default-secret
      imagePullSecrets:
        - name: swr-secret
 
---
 
apiVersion: v1
kind: Service
metadata:
  name: sub1-pod1-nodeport
  namespace: sub1
spec:
  type: NodePort
  selector:
    app: sub1pod1
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8103
      nodePort: 32700
 
---
 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sub1-pod2
  namespace: sub1
spec:
  selector:
    matchLabels:
      app: sub1pod2
  replicas: 1
  template:
    metadata:
      labels:
        app: sub1pod2
    spec:
      containers:
      - name: my-test01-02
        image: swr.cn-east-3.myhuaweicloud.com/k8s-imgs/account-platform-admin:dev01-084e7d9
        imagePullPolicy: IfNotPresent
      imagePullSecrets:
      - name: default-secret
      imagePullSecrets:
        - name: swr-secret
     
---
 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sub2-pod1
  namespace: sub2
spec:
  selector:
    matchLabels:
      app: sub2pod1
  replicas: 1
  template:
    metadata:
      labels:
        app: sub2pod1
    spec:
      containers:
      - name: my-test02-01
        image: swr.cn-east-3.myhuaweicloud.com/k8s-imgs/account-platform-admin:dev01-084e7d9
        imagePullPolicy: IfNotPresent
      imagePullSecrets:
      - name: default-secret
      imagePullSecrets:
        - name: swr-secret
---
 
apiVersion: v1
kind: Service
metadata:
  name: sub2-pod1-nodeport
  namespace: sub2
spec:
  type: NodePort
  selector:
    app: sub2pod1
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8103
      nodePort: 32701
 
---
 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sub2-pod2
  namespace: sub2
spec:
  selector:
    matchLabels:
      app: sub2pod2
  replicas: 1
  template:
    metadata:
      labels:
        app: sub2pod2
    spec:
      containers:
      - name: my-test02-02
        image: swr.cn-east-3.myhuaweicloud.com/k8s-imgs/account-platform-admin:dev01-084e7d9
        imagePullPolicy: IfNotPresent
      imagePullSecrets:
      - name: default-secret
      imagePullSecrets:
        - name: swr-secret
 
---
 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sub3-pod1
  namespace: sub3
spec:
  selector:
    matchLabels:
      app: sub3pod1
  replicas: 1
  template:
    metadata:
      labels:
        app: sub3pod1
    spec:
      containers:
      - name: my-test03-01
        image: swr.cn-east-3.myhuaweicloud.com/k8s-imgs/account-platform-admin:dev01-084e7d9
        imagePullPolicy: IfNotPresent
      imagePullSecrets:
      - name: default-secret
      imagePullSecrets:
        - name: swr-secret　　

查看创建的资源

3、应用策略之前测试

在应用网络策略之前测试各pod之间、pod和外网之间是否可以通信。

sub1-pod1 ping sub1-pod2、sub2-pod1、sub3-pod1、qq.com

外部节点ping sub1-pod1-nodeport、sub2-pod1-nodeport

取k8s集群任一节点ip  10.34.106.14

 总结：通过以上测试证明未加网络策略之前pod之间，pod外网之间都是互通的。

4、创建网络策略1-pod隔离 

策略描述：在sub1中创建策略，使sub1中pod之间无法通信且和其他命名空间pod也无法通信，只能进出外网。测试流程：　　

4.1、sub1-pod1、sub1-pod2、sub2-pod1三者之间互ping不通；　　

4.2、sub1-pod1、sub1-pod2可以ping通外网(包含域名)，外网也能和sub1-pod1-nodeport通信；

本k8s集群pod cidr为：10.243.0.0/16

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: pod-policy
  namespace: sub1
spec:
  podSelector: {}
  ingress:
    - from:
      - ipBlock:
          cidr: 0.0.0.0/0
          except:
          - 10.243.0.0/16
  egress:
    - to:
      - ipBlock:
          cidr: 0.0.0.0/0
          except:
          - 10.243.0.0/16
  policyTypes:
  - Egress
  - Ingress

解释：

  1. podSelector: {} 表示选择命名空间中的所有 Pod。

  2. ingress: 定义了进入命名空间的流量控制规则。from: 表示允许来自哪些来源的流量。ipBlock: 表示允许来自除了 10.243.0.0/16 CIDR 地址范围之外的所有 IP 地址的流量。

  3. egress: 定义了离开命名空间的流量控制规则。to: 表示允许流向哪些目的地的流量。ipBlock: 表示允许流向除了 10.243.0.0/16 CIDR 地址范围之外的所有 IP 地址的流量。

  4. policyTypes: 指定 NetworkPolicy 控制的流量类型，这里包括 Ingress 和 Egress。

效果：

  • Ingress: 允许所有来源的流量，除了 CIDR 地址范围 10.243.0.0/16。

  • Egress: 允许流向所有目的地的流量，除了 CIDR 地址范围 10.243.0.0/16。

测试：

创建策略

 sub1-pod1  ping  sub1-pod2和sub2-pod1 （不通）

 sub2-pod1  ping  sub1-pod1和sub1-pod2（不通）

 sub1-pod1  ping  外网ip（通）

 sub1-pod1  ping  域名（不通）-- 因为域名解析服务dns在kube-system空间，而sub1屏蔽了所有空间，下面示例可解决。

外部访问sub1-pod1-nodeport（通）

取k8s集群任一节点ip  10.34.106.14

5、创建网络策略2-命名空间隔离

策略描述：在sub2中创建策略，使sub2中pod之间可以通信但和其他命名空间pod无法通信，也能进出外网。测试流程：　　

5.1、sub2-pod1和sub2-pod2之间互ping可通；　　

5.2、sub2-pod1、sub2-pod2和sub3-pod1之间互ping不通；　　

5.3、sub2-pod1、sub2-pod2可以ping通外网(包含域名)，外网也能和sub2-pod1-nodeport通信；

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: sub2
  namespace: sub2
spec:
  podSelector: {}
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 10.243.0.0/16
    - namespaceSelector:    # 如果不想给命名空间加label，可以换成   - podSelector: {} # 允许来自同一命名空间中的所有 Pod 的流量
        matchLabels:
          ns: sub2
  ingress:
  - from:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 10.243.0.0/16
    - namespaceSelector:    # 如果不想给命名空间加label，可以换成   - podSelector: {} # 允许来自同一命名空间中的所有 Pod 的流量
        matchLabels:
          ns: sub2
  policyTypes:
  - Egress
  - Ingress

解释

  1. podSelector: {} 表示选择命名空间中的所有 Pod。

  2. ingress: 定义了进入命名空间的流量控制规则。from: 表示允许来自哪些来源的流量。ipBlock: 表示允许来自除了 10.243.0.0/16 CIDR 地址范围之外的所有 IP 地址的流量。namespaceSelector: 表示允许来自具有标签 ns=sub2 的命名空间中的 Pod 的流量。from字段中的 podSelector: {} 表示允许来自同一命名空间中的所有 Pod 的流量。

  3. egress: 定义了离开命名空间的流量控制规则。to: 表示允许流向哪些目的地的流量。ipBlock: 表示允许流向除了 10.243.0.0/16 CIDR 地址范围之外的所有 IP 地址的流量。namespaceSelector: 表示允许流向具有标签 ns=sub2 的命名空间中的 Pod 的流量。to字段中的 podSelector: {} 表示允许流向同一命名空间中的所有 Pod 的流量。

  4. policyTypes: 指定 NetworkPolicy 控制的流量类型，这里包括 Ingress 和 Egress。

效果

  • Ingress: 允许所有来源的流量，除了 CIDR 地址范围 10.243.0.0/16 和来自其他命名空间的流量，如果使用namespaceSelector则允许进入命名空间具有标签 ns=sub2中的pod，如果使用podSelector: {}表示允许来自同一命名空间中的所有 Pod 的流量。

  • Egress: 允许流向所有目的地的流量，除了 CIDR 地址范围 10.243.0.0/16 和流向其他命名空间的流量，如果使用namespaceSelector则允许流向命名空间具有标签 ns=sub2中的pod，如果使用podSelector: {}表示允许流向同一命名空间中的所有 Pod 的流量。

测试

创建策略

sub2-pod1  ping  sub2-pod2（通）

sub2-pod1  ping  sub3-pod1（不通）

sub3-pod1  ping  sub2-pod1、sub2-pod2（不通）

sub2-pod1  ping  外网ip（通）

sub2-pod1  ping  域名（不通）-- 因为域名解析服务dns在kube-system空间，而sub1屏蔽了所有空间，下面示例可解决。

外部 访问sub2-pod1-nodeport（通）

取k8s集群任一节点ip  10.34.106.14

6、创建网络策略3-业务命名空间隔离

实际应用中某些命名空间中的pod可能和其他命名空间中的pod有调用关系，还可能用到一些系统命名空间中的服务（如DNS服务），所以不能将某个命名空间完全和其他所有命名空间隔离，只需要将确定没有业务调用的命名空间隔离。

策略描述：更新第5步sub2中创建的策略，使sub2中的pod除了不能和sub3中的pod通信外，和其他所有地址都可通信。

测试流程：

　　6.1、sub2-pod1和sub2-pod2互ping可通；

　　6.2、sub2-pod1和kube-system命名空间中的coredns-pod之间互ping可通；

　　6.3、sub2-pod1和sub3-pod1互ping不通；

　　6.4、sub2-pod1可以ping通外网（域名），外网也能和sub2-pod1-nodeport通信；

由于没有直接阻止具有某个label的命名空间配置，所有只能间接通过放行具有某些labels的命名空间以达到阻止的目的。

label设置比较灵活，可根据实际情况配置，有一下几种方式可供参考：

1、可以将放行的所有命名空间配置一个统一的label，这样只需要在配置中放行具有这个label的命名空间即可；

2、也可给每个命名空间配置一个label，这样需要在配置中放行各个不同label的命名空间；

3、可以将通用的系统命名空间设置一个统一的label，给业务命名空间配置不同的label；

本例采用第2种，给所有需要放行的命名空间配置不同的label；

命名空间加label

kubectl label ns kube-system ns=kube-system
kubectl label ns kuboard ns=kuboard
kubectl label ns kube-public ns=kube-public

网络隔离配置

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: ns-policy-2
  namespace: sub2
spec:
  podSelector: {}
  ingress:
  - from:
    - podSelector: {}
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 10.243.0.0/16
  - from:
    - namespaceSelector:
        matchLabels:
          ns: kube-system
  - from:
    - namespaceSelector:
        matchLabels:
          ns: kuboard
  - from:
    - namespaceSelector:
        matchLabels:
          ns: kube-public
  egress:
  - to:
    - podSelector: {}
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 10.243.0.0/16
  - to:
    - namespaceSelector:
        matchLabels:
          ns: kube-system
  - to:
    - namespaceSelector:
        matchLabels:
          ns: kuboard
  - to:
    - namespaceSelector:
        matchLabels:
          ns: kube-public
  policyTypes:
  - Egress
  - Ingress

解释

  • podSelector: {} 表示选择命名空间中的所有 Pod。

  • policyTypes: Ingress 和 Egress 表示同时控制进入和离开命名空间的流量。

  • ingress: from 字段中的 podSelector: {} 表示允许来自同一命名空间中的所有 Pod 的流量；ipBlock 表示允许来自除了 Kubernetes 内部网络 CIDR 地址范围10.243.0.0/16

  • 之外的所有 IP 地址的流量。

  • egress: to 字段中的 podSelector: {} 表示允许流向同一命名空间中的所有 Pod 的流量；ipBlock 表示允许流向除了 Kubernetes 内部网络 CIDR 地址范围10.243.0.0/16

  •  之外的所有 IP 地址的流量。

  • from 和 to: 使用 namespaceSelector 允许放行具有标签 ns=kube-system、ns=kuboardns、ns=kube-public的命名空间中的 Pod 的流量，间接阻止了其他命名空间的流量。

测试

创建策略

sub2-pod1  ping  sub2-pod2（通）

sub2-pod1  ping  kube-system命名空间中的coredns-pod（通）

sub2-pod1  ping  sub3-pod1（不通）

sub2-pod1可以ping通外网、域名（通）

外部 访问sub2-pod1-nodeport（通）

取k8s集群任一节点ip  10.34.106.14

文章转载自：技术人的菜园子

原文链接：https://www.cnblogs.com/wangjiayu/p/18381458

体验地址：引迈 - JNPF快速开发平台_低代码开发平台_零代码开发平台_流程设计器_表单引擎_工作流引擎_软件架构

工业甲酰苯胺
关注
K8S---NetworkPolicy
qq_41768644的博客
01-18 495
K8S--networkpolicy
k8s学习-网络策略NetworkPolicy（概念、模版、创建、删除等）
m0_54903333的博客
04-26 1090
如果你希望在 IP 地址或端口层面（OSI 第 3 层或第 4 层）控制网络流量， 则你可以考虑为集群中特定应用使用 Kubernetes 网络策略（NetworkPolicy）。是一种以应用为中心的结构，允许你设置如何允许与网络上的各类网络“实体” （我们这里使用实体以避免过度使用诸如“端点”和“服务”这类常用术语， 这些术语在 Kubernetes 中有特定含义）。NetworkPolicies 适用于一端或两端与 Pod 的连接，与其他连接无关。
Kubernetes网络隔离
Holmes的博客
06-25 715
Kubernetes网络隔离 Network Policies 隔离手段：NetworkPolicy 要在Kubernetes集群中使用NetworkPolicy，CNI网络插件必须维护一个NetworkPolicy Controller，支持Kubernetes 的NetworkPolicy。实现了NetworkPolicy的网络插件包括Weave和Calico等，但不包括Flannel。通过控制循环的方式对NetworkPolicy对象的增删改查作出响应，然后在宿主机上完成iptables规则的配置工作
k8s networkpolicy
小诸葛的博客
02-21 1075
通俗理解Network Policy：谁能访问我(Ingress)和我能访问谁(Egress) 隔离指定分区的指定pod，设置这些pod的访问规则： Ingress：哪些分区(namespaceSelector)的哪些pod(podSelector)可以访问我的哪些端口(ports) Egress：我可以访问哪些分区(namespaceSelector)的哪些pod(podSelector)的哪些端口(ports) ...
Kubernetes（k8s）的Network Policies解析
最新发布
专注于数据库技术分享，包含但不限于Oracle，MySQL，PostgreSQL，ElasticSearch及国产数据库等
05-10 638
Kubernetes（k8s）的是一种资源对象，用于定义Pod之间的网络通信规则，以此来控制和隔离集群内部的网络流量。这为Kubernetes集群提供了更细粒度的网络安全控制能力。
Kubernetes集群中的高性能网络策略
weixin_33726318的博客
12-08 256
自从7月份发布Kubernetes 1.3以来，用户已经能够在其集群中定义和实施网络策略。这些策略是防火墙规则，用于指定允许流入和流出的数据类型。如果需要，Kubernetes可以阻止所有未明确允许的流量。本文针对K8s的网络策略进行介绍并对网络性能进行测试。 网络策略 K8s的网络策略应用于通过常用标签标识的pod组。然后，可以使用标签...
k8s学习-网络策略NetworkPolicy（概念、模版、创建、删除等）(1)
2401_84253380的博客
04-28 904
Python编程学习，学习内容包含：语法、正则、文件、 网络、多线程等常用库，推荐《Python核心编程》，不要看完；在实际的渗透测试过程中，面对复杂多变的网络环境，当常用工具不能满足实际需求的时候，往往需要对现有工具进行扩展，或者编写符合我们要求的工具、自动化脚本，这个时候就需要具备一定的编程能力。恭喜你，如果学到这里，你基本可以从事一份网络安全相关的工作，比如渗透测试、Web 渗透、安全服务、安全分析等岗位；k8s的Pod是没有隔离行的，任意命名空间下的Pod可以访问任意命名空间下的Pod。
k8s-kubernetes--网络策略、flannel网络插件和calico网络插件
Gong_yz的博客
03-12 6103
网络策略通过网络插件来实现。要使用网络策略，你必须使用支持 NetworkPolicy 的网络解决方案。 创建一个 NetworkPolicy 资源对象而没有控制器来使它生效的话，是没有任何作用的。(Flannel不支持 NetworkPolicy，所以使用Flannei网络插件是不会隔离pod的)
k8s-security-demos：几个kubernetes安全功能的演示
02-04
3. **Network Policies**: Kubernetes的网络策略允许对Pod间的网络通信进行细粒度控制，实现安全隔离。你可以定义规则，只允许特定的流量进出特定的Pod，以此来防止未授权的通信。 4. **Security Context**: ...
K8S NetworkPolicy网络策略介绍与实战
Vic的博客
06-08 2056
默认情况下，Kubernetes 集群网络没任何网络限制，Pod 可以与任何其他 Pod 通信，在某些场景下就需要进行网络控制，减少网络攻击面，提高安全性，这就会用到网络策略。
k8s 之NetworkPolicy介绍使用
魏志标的博客
03-21 1452
k8s之networkpolicy 应用
k8s集群网络策略（Network Policy）
砚墨
07-04 1831
默认情况下，Kubernetes 集群网络没任何网络限制，Pod 可以与任何其他 Pod 通信，在某些场景下就需要进行网络控制，减少网络攻击面，提高安全性，这就会用到网络策略。 网络策略（Network Policy）：是一个K8s资源，用于限制Pod出入流量，提供Pod级别和Namespace级别网络访问控制。 网络策略的应用场景： • 应用程序间的访问控制，例如项目A不能访问项目B的Pod • 开发环境命名空间不能访问测试环境命名空间Pod • 当Pod暴露到外部时，需要做Pod白名单 • 多租户网络环
k8s network policy配置，看这篇就够了
weixin_36086263的博客
06-10 6424
这是一篇关于k8s的网络策略配置说明 用户在使用k8s中，有对网络策略的配置需求，有时候希望不同的namespace之间不能互相访问，但是我们知道k8s中所有的pod之间都是可以互相访问的，这个时候就需要网络策略来帮助我们实现这个诉求，网络策略依赖于cni网络插件，不是所有的网络插件都支持网络策略，calico支持网络策略，而flannel不支持。 接下来我以一张图来说明k8s的networkpolicy资源的配置 整个图总接下来如下： 入口规则： 仅允许 1.来自（from）命名空间（spec
K8S学习指南(29)-k8s网络对象NetworkPolicy
俞兆鹏的博客
12-20 3487
NetworkPolicy是Kubernetes中用于定义Pod之间网络通信规则的资源对象。通过NetworkPolicy，开发者可以控制哪些Pod可以与另外哪些Pod通信，以及使用何种方式进行通信。这种细粒度的网络控制有助于提高集群的安全性，防止未经授权的访问和通信。
十九. Kubernetes NetworkPolicy 网络隔离策略
qq_29799655的博客
05-25 684
【代码】十九. Kubernetes NetworkPolicy 网络隔离策略。
2、玩转k8s之网络策略 network policy 快速入门
weixin_40807433的博客
02-29 1038
当为namespaceSelector选中 kubernetes.io/metadata.name 为 lisi 的时候，此刻该名称空间下的所有pod 都能访问 目标 tanqidi 名称空间下的 tanqidi-db的pod，但是紧接着你使用了 and关系添加了podSelector 为 app: lisi-service，换而言之条件就变小了变成 lisi的namespace 下的 lisi-service的pod能访问目标 tanqidi 名称空间下的 tanqidi-db的pod。
2024年最全k8s学习-网络策略NetworkPolicy（概念、模版、创建、删除等），网络安全面试2024
2401_84545884的博客
05-05 1058
Python编程学习，学习内容包含：语法、正则、文件、 网络、多线程等常用库，推荐《Python核心编程》，不要看完；在实际的渗透测试过程中，面对复杂多变的网络环境，当常用工具不能满足实际需求的时候，往往需要对现有工具进行扩展，或者编写符合我们要求的工具、自动化脚本，这个时候就需要具备一定的编程能力。恭喜你，如果学到这里，你基本可以从事一份网络安全相关的工作，比如渗透测试、Web 渗透、安全服务、安全分析等岗位；③漏洞扫描、漏洞利用、原理，利用方法、工具（MSF）、绕过IDS和反病毒侦察。
Calico网络隔离与NetworkPolicy实战
"本文主要探讨了如何利用Calico和Kubernetes的NetworkPolicy实现租户间的网络隔离，包括Calico的基本介绍、其架构以及NetworkPolicy的详细解析和应用案例。" 在Kubernetes环境中，网络隔离是确保多租户安全性的关键...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值