24.4. OVN-Kubernetes 网络策略
AdminNetworkPolicy
资源只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围。
Kubernetes 提供了两个用户可用于强制实施网络安全的功能。允许用户强制执行网络策略的一个功能是 NetworkPolicy
API,主要用于应用程序开发人员和命名空间租户,通过创建命名空间范围的策略来保护其命名空间。如需更多信息,请参阅关于网络策略。
第二个功能是 AdminNetworkPolicy
,它由两个 API 组成:AdminNetworkPolicy
(ANP) API 和 BaselineAdminNetworkPolicy
(BANP) API。ANP 和 BANP 是为集群和网络管理员设计的,以通过创建集群范围的策略来保护其整个集群。集群管理员可以使用 ANPs 来强制实施优先于 NetworkPolicy
对象的不可覆盖的策略。管理员可以使用 BANP 来设置并强制实施可选的集群范围的网络策略规则,这些策略规则供用户使用 NetworkPolicy
对象(如果需要的话)覆盖。当与 ANP 和 BANP 一起使用时,管理员可以创建多租户策略,供管理员用来保护其集群。
OpenShift Container Platform 中的 OVN-Kubernetes CNI 使用访问控制列表(ACL) Tiers 实施这些网络策略,以评估并应用它们。ACL 按照从 Tier 1 到 Tier 3 的降序进行评估。
第 1 级评估 AdminNetworkPolicy
(ANP)对象。第 2 级评估 NetworkPolicy
对象。第 3 级评估 BaselineAdminNetworkPolicy
(BANP)对象。
图 24.3. OVK-Kubernetes 访问控制列表 (ACL)
如果流量与 ANP 规则匹配,将首先评估 ANP 中的规则。如果匹配项是 ANP allow
或 deny
规则,则集群中的任何现有 NetworkPolicies
和 BaselineAdminNetworkPolicy
(BANP)都会从评估中意外跳过。如果匹配项是 ANP pass
规则,则评估将从 ACL 的级 1 移动到级 2 (评估 NetworkPolicy
策略)。
24.4.1. AdminNetworkPolicy
AdminNetworkPolicy
(ANP)是一个集群范围的自定义资源定义(CRD)。作为 OpenShift Container Platform 管理员,您可以在创建命名空间前通过创建网络策略来使用 ANP 来保护网络。另外,您可以在集群范围的级别上创建网络策略,该级别不可由 NetworkPolicy
对象覆盖。
AdminNetworkPolicy
和 NetworkPolicy
对象之间的关键区别在于,供管理员使用,是集群范围,而后者则用于租户所有者,并且是命名空间范围。
ANP 允许管理员指定以下内容:
-
确定其评估顺序的
priority
值。数值越低,优先级越高。 -
由一组命名空间或命名空间的
subject
。 -
要应用到
subject
的所有入口流量的入站规则列表。 -
用于来自
subject
的所有出口流量的出口规则列表。
AdminNetworkPolicy
资源是一个 TechnologyPreviewNoUpgrade
功能,可在非生产环境的测试环境中启用。有关功能门和技术 PreviewNoUpgrade
功能的更多信息,请参阅本节"添加资源"中的"使用功能门启用功能"。
AdminNetworkPolicy 示例
例 24.1. ANP 的 YAML 文件示例
apiVersion: policy.networking.k8s.io/v1alpha1 kind: AdminNetworkPolicy metadata: name: sample-anp-deny-pass-rules 1 spec: priority: 50 2 subject: namespaces: matchLabels: kubernetes.io/metadata.name: example.name 3 ingress: 4 - name: "deny-all-ingress-tenant-1" 5 action: "Deny" from: - pods: namespaces: 6 namespaceSelector: matchLabels: custom-anp: tenant-1 podSelector: matchLabels: custom-anp: tenant-1 7 egress:8 - name: "pass-all-egress-to-tenant-1" action: "Pass" to: - pods: namespaces: namespaceSelector: matchLabels: custom-anp: tenant-1 podSelector: matchLabels: custom-anp: tenant-1
- 1
- 为您的 ANP 指定一个名称。
- 2
spec.priority
字段支持集群中 0-99 值中最多 100 ANP。数值越低,优先级越高。创建具有相同优先级的AdminNetworkPolicy
会创建非确定的结果。- 3
- 指定要应用 ANP 资源的命名空间。
- 4
- ANP 具有入口和出口规则。
spec.ingress
字段的 ANP 规则接受Pass
,Deny
,action
字段接受的值为Allow
。 - 5
- 为
ingress.name
指定一个名称。 - 6
- 指定要从中选择 pod 以应用 ANP 资源的命名空间。
- 7
- 指定要应用 ANP 资源的 pod 的
podSelector.matchLabels
名称。 - 8
- ANP 具有入口和出口规则。
spec.egress
字段的 ANP 规则接受Pass
,Deny
,action
字段接受的值为Allow
。
24.4.1.1. 规则的 AdminNetworkPolicy 操作
作为管理员,您可以将您的 AdminNetworkPolicy
规则的 action
字段设置为 Allow
,Deny
, 或 Pass
。由于 OVN-Kubernetes 使用分层 ACL 来评估网络流量规则,因此 3NP 允许您设置非常强大的策略规则,它们只能被管理员修改、删除规则,或通过设置更高优先级规则来覆盖它们。
AdminNetworkPolicy Allow 示例
在优先级 9 中定义的以下 ANP 可确保允许从 monitoring
命名空间到集群中的任何租户(所有其他命名空间)的所有入口流量。
例 24.2. 强 Allow
ANP 的 YAML 文件示例
apiVersion: policy.networking.k8s.io/v1alpha1 kind: AdminNetworkPolicy metadata: name: allow-monitoring spec: priority: 9 subject: namespaces: {} ingress: - name: "allow-ingress-from-monitoring" action: "Allow" from: - namespaces: namespaceSelector: matchLabels: kubernetes.io/metadata.name: monitoring # ...
这是强的 Allow
ANP 的示例,因为它不可以被涉及的所有方覆盖。租户都不会阻止自己被使用 NetworkPolicy
对象监控,监控租户也不知道它可以或无法监控的内容。
AdminNetworkPolicy 拒绝示例
在优先级 5 中定义的以下 ANP 可确保 monitoring
命名空间中的所有入口流量都被阻止到受限租户(具有标签 security: restricted
的命名空间)。
例 24.3. 强 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: namespaceSelector: matchLabels: kubernetes.io/metadata.name: monitoring # ...
这是一个强大的 Deny
ANP,这是所有涉及的方都无法覆盖的。受限租户所有者无法授权自己允许监控流量,基础架构监控服务无法从这些敏感命名空间中提取任何内容。
与强的 Allow
示例结合使用时,block-monitoring
ANP 具有较低优先级的值,赋予其优先级更高的优先级,这样可确保不会监控受限租户。
AdminNetworkPolicy Pass 示例
在优先级 7 定义的以下 ANP 可确保所有从 monitoring
命名空间到内部基础架构租户(具有标签 security: internal
)的入口流量都将传递到 ACL 的层 2,并由命名空间的 NetworkPolicy
对象评估。
例 24.4. 强 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: namespaceSelector: matchLabels: kubernetes.io/metadata.name: monitoring # ...
这个示例是一个强大的 Pass
操作 ANP,因为它将决策委派给租户所有者定义的 NetworkPolicy
对象。如果基础架构监控服务应使用命名空间范围 NetworkPolicy
对象提取其指标,则此 pass-monitoring
ANP 允许在安全级别 internal
分组的所有租户所有者。
24.4.2. BaselineAdminNetworkPolicy
BaselineAdminNetworkPolicy
(BANP)是一个集群范围的自定义资源定义(CRD)。作为 OpenShift Container Platform 管理员,您可以使用 BANP 来设置并强制实施可选的基准网络策略规则,这些规则被用户使用 NetworkPolicy
对象(如果需要的话)覆盖。BANP 的规则操作是 allow
或 deny
。
BaselineAdminNetworkPolicy
资源是一个集群单例对象,当传递的流量策略与集群中的任何 NetworkPolicy
对象不匹配时,可用作 guardrail 策略。BANP 也可以用作默认安全模型,该模型默认阻止集群内流量,用户需要使用 NetworkPolicy
对象来允许已知的流量。在创建 BANP 资源时,必须使用 default
作为名称。
管理员可通过 BANP 指定:
-
由一组命名空间或命名空间的
subject
。 -
要应用到
subject
的所有入口流量的入站规则列表。 -
用于来自
subject
的所有出口流量的出口规则列表。
BaselineAdminNetworkPolicy
资源是一个 TechnologyPreviewNoUpgrade
功能,可在非生产环境的测试环境中启用。
BaselineAdminNetworkPolicy 示例
例 24.5. BANP 的 YAML 文件示例
apiVersion: policy.networking.k8s.io/v1alpha1 kind: BaselineAdminNetworkPolicy metadata: name: default 1 spec: subject: namespaces: matchLabels: kubernetes.io/metadata.name: example.name 2 ingress: 3 - name: "deny-all-ingress-from-tenant-1" 4 action: "Deny" from: - pods: namespaces: namespaceSelector: matchLabels: custom-banp: tenant-1 5 podSelector: matchLabels: custom-banp: tenant-1 6 egress: - name: "allow-all-egress-to-tenant-1" action: "Allow" to: - pods: namespaces: namespaceSelector: matchLabels: custom-banp: tenant-1 podSelector: matchLabels: custom-banp: tenant-1
BaselineAdminNetworkPolicy 拒绝示例
以下 BANP 单例确保管理员为 internal
安全级别进入租户的所有入口监控流量设置了默认的拒绝策略。与 "AdminNetworkPolicy Pass example" 组合时,这个 deny 策略充当 ANP pass-monitoring
策略传递的所有入口流量的保护策略。
例 24.6. guardrail Deny
规则的 YAML 文件示例
apiVersion: policy.networking.k8s.io/v1alpha1 kind: BaselineAdminNetworkPolicy metadata: name: default spec: subject: namespaces: matchLabels: security: internal ingress: - name: "deny-ingress-from-monitoring" action: "Deny" from: - namespaces: namespaceSelector: matchLabels: kubernetes.io/metadata.name: monitoring # ...
您可以将带有 action
字段的值为 Pass
的 AdminNetworkPolicy
资源与 BaselineAdminNetworkPolicy
资源结合使用来创建多租户策略。此多租户策略允许一个租户在应用上收集监控数据,同时不从第二个租户收集数据。
作为管理员,如果您同时应用了 "AdminNetworkPolicy Pass
action example" 和 "BaselineAdminNetwork Policy Deny
example",则租户将保留创建在 BANP 之前评估的 NetworkPolicy
资源。
例如,租户 1 可以设置以下 NetworkPolicy
资源来监控入口流量:
例 24.7. NetworkPolicy
示例
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-monitoring namespace: tenant 1 spec: podSelector: policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: monitoring # ...
在这种情况下,Tenant 1 会在 "AdminNetworkPolicy Pass
action example" 之后,"BaselineAdminNetwork Policy Deny
example" 之前被评估,它将拒绝所有进入 安全
级别 internal
的入口监控流量。随着租户 1 的 NetworkPolicy
对象就位,它们将能够在其应用程序中收集数据。但是,租户 2 没有任何 NetworkPolicy
对象,将无法收集数据。作为管理员,您没有默认监控内部租户,而是创建了 BANP,它允许租户使用 NetworkPolicy
对象覆盖 BANP 的默认行为。