第 2 章 管理网络策略
2.1. OVN-Kubernetes AdminNetworkPolicy 复制链接链接已复制到粘贴板!
在 OpenShift Container Platform 中,您可以将 AdminNetworkPolicy 资源配置为强制命名空间范围的 NetworkPolicy 对象无法覆盖集群范围的入口和出口规则,这会保留对多租户隔离和平台安全性的管理控制。
2.1.1. AdminNetworkPolicy 复制链接链接已复制到粘贴板!
AdminNetworkPolicy (ANP)是一个集群范围的自定义资源定义(CRD),您可以在命名空间创建前建立入口和出口规则。您可以使用 ANPs 来确保租户 NetworkPolicy 对象无法覆盖您的管理控制。
AdminNetworkPolicy 和 NetworkPolicy 对象的主要区别在于,前者是管理员的,是集群范围,后者则用于租户所有者,是命名空间范围。
ANP 允许管理员指定以下内容:
-
确定其评估顺序的
priority值。数值越低,优先级越高。 - 由应用策略的一组命名空间或命名空间组成的一组 pod。
-
要应用到
subject的所有入口流量的入站规则列表。 -
用于来自
subject的所有出口流量的出口规则列表。
2.1.1.1. AdminNetworkPolicy 示例 复制链接链接已复制到粘贴板!
ANP 的 YAML 文件示例
apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
name: sample-anp-deny-pass-rules
spec:
priority: 50
subject:
namespaces:
matchLabels:
kubernetes.io/metadata.name: example.name
ingress:
- name: "deny-all-ingress-tenant-1"
action: "Deny"
from:
- pods:
namespaceSelector:
matchLabels:
custom-anp: tenant-1
podSelector:
matchLabels:
custom-anp: tenant-1
egress:
- name: "pass-all-egress-to-tenant-1"
action: "Pass"
to:
- pods:
namespaceSelector:
matchLabels:
custom-anp: tenant-1
podSelector:
matchLabels:
custom-anp: tenant-1
其中:
metadata.name- 为您的 ANP 指定名称。
spec.priority-
指定 ANP 的优先级。支持集群中值
0-99范围中最多 100 ANPs。数越低,优先级越高,因为范围是从按最低到最高值的顺序读取的。因为当以同一优先级创建 ANP 时,无法保证哪些策略会被优先使用,所以请使用不同的优先级来设置 ANPs。 spec.subject.namespaces.matchLabels- 指定要应用 ANP 资源的命名空间。
spec.ingress.name-
为
ingress.name指定名称。 spec.ingress.action-
为 ANP 指定入站规则。ANP 具有入口和出口规则。接受
Pass、Deny和Allow的值。 spec.ingress.from.pods.namespaceSelector.matchLabels-
指定
podSelector.matchLabels,以选择namespaceSelector.matchLabels作为入口对等选择的命名空间中的 pod。 spec.egress.action-
为 ANP 指定出口规则。接受
Pass、Deny和Allow的值。
2.1.1.2. 规则的 AdminNetworkPolicy 操作 复制链接链接已复制到粘贴板!
您可以将 action 字段设置为 Allow,Deny, 或 Pass on 每个 AdminNetworkPolicy(ANP)自定义资源规则,以便在较低层网络policies 前应用管理决策。
因为 OVN-Kubernetes 使用分层 ACL 来评估网络流量规则,所以 ANP CR 可让您定义强大的策略规则,这些规则只能由管理员修改、删除规则或通过设置更高的优先级规则来覆盖它们。
2.1.1.2.1. AdminNetworkPolicy Allow 示例 复制链接链接已复制到粘贴板!
在优先级 9 中定义的以下 ANP 可确保允许从 monitoring 命名空间到集群中的任何租户(所有其他命名空间)的所有入口流量。
强 Allow ANP 的 YAML 文件示例
apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
name: allow-monitoring
spec:
priority: 9
subject:
namespaces: {} # Use the empty selector with caution because it also selects OpenShift namespaces as well.
ingress:
- name: "allow-ingress-from-monitoring"
action: "Allow"
from:
- namespaces:
matchLabels:
kubernetes.io/metadata.name: monitoring
# ...
这是强的 Allow ANP 的示例,因为它不可以被涉及的所有方覆盖。租户都不会阻止自己被使用 NetworkPolicy 对象监控,监控租户也不知道它可以或无法监控的内容。
2.1.1.2.2. AdminNetworkPolicy 拒绝示例 复制链接链接已复制到粘贴板!
在优先级 5 中定义的以下 ANP 可确保 monitoring 命名空间中的所有入口流量都被阻止到受限租户(具有标签 security: restricted的命名空间)。
强 Deny ANP 的 YAML 文件示例
apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
name: block-monitoring
spec:
priority: 5
subject:
namespaces:
matchLabels:
security: restricted
ingress:
- name: "deny-ingress-from-monitoring"
action: "Deny"
from:
- namespaces:
matchLabels:
kubernetes.io/metadata.name: monitoring
# ...
这是一个强大的 Deny ANP,这是所有涉及的方都无法覆盖的。受限租户所有者无法授权自己允许监控流量,基础架构监控服务无法从这些敏感命名空间中提取任何内容。
当与强大的 Allow 示例结合使用时,block-monitoring ANP 具有较低的优先级值赋予它更高的优先级,这样可确保不监控 受限 租户。
2.1.1.2.3. AdminNetworkPolicy Pass 示例 复制链接链接已复制到粘贴板!
在优先级 7 定义的以下 ANP 可确保所有从 monitoring 命名空间到内部基础架构租户(具有标签 security: internal)的入口流量都将传递到 ACL 的层 2,并由命名空间的 NetworkPolicy 对象评估。
强 Pass ANP 的 YAML 文件示例
apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
name: pass-monitoring
spec:
priority: 7
subject:
namespaces:
matchLabels:
security: internal
ingress:
- name: "pass-ingress-from-monitoring"
action: "Pass"
from:
- namespaces:
matchLabels:
kubernetes.io/metadata.name: monitoring
# ...
这个示例是一个强大的 Pass 操作 ANP,因为它将决策委派给租户所有者定义的 NetworkPolicy 对象。如果基础架构监控服务应使用命名空间范围 NetworkPolicy 对象提取其指标,则此 pass-monitoring ANP 允许在安全级别 internal 分组的所有租户所有者。