关于 AdminNetworkPolicy - 网络安全 | 网络 | Red Hat OpenShift Service on AWS

AdminNetworkPolicy
- 规则的 AdminNetworkPolicy 操作

AdminNetworkPolicy

AdminNetworkPolicy (ANP) 是集群范围的自定义资源定义 (CRD)。作为 Red Hat OpenShift Service on AWS 管理员，您可以使用 ANP 通过在创建命名空间之前创建网络策略来保护您的网络。此外，您可以在集群范围内创建不可被NetworkPolicy 对象覆盖的网络策略。

AdminNetworkPolicy 和 NetworkPolicy 对象之间的主要区别在于，前者面向管理员且具有集群范围，而后者面向租户所有者且具有命名空间范围。

ANP 允许管理员指定以下内容：

确定其评估顺序的priority 值。值越低，优先级越高。
由一组命名空间或命名空间组成的，应用策略的一组 Pod。
应用于所有针对subject 的入口流量的入口规则列表。
应用于所有来自subject 的出口流量的出口规则列表。

AdminNetworkPolicy 示例

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:
        namespaceSelector:
          matchLabels:
            custom-anp: tenant-1
        podSelector:
          matchLabels:
            custom-anp: tenant-1 (6)
  egress:(7)
  - name: "pass-all-egress-to-tenant-1"
    action: "Pass"
    to:
    - pods:
        namespaceSelector:
          matchLabels:
            custom-anp: tenant-1
        podSelector:
          matchLabels:
            custom-anp: tenant-1

1	为您的 ANP 指定一个名称。
2	`spec.priority` 字段支持集群中 0-99 范围内的最多 100 个 ANP。值越低，优先级越高，因为范围是从最低值到最高值按顺序读取。由于无法保证在同一优先级下创建的 ANP 中哪个策略优先，因此请设置不同优先级的 ANP，以便优先级是有意的。
3	指定要应用 ANP 资源的命名空间。
4	ANP 同时具有入口和出口规则。`spec.ingress` 字段的 ANP 规则为`action` 字段接受`Pass`、`Deny` 和`Allow` 值。
5	为`ingress.name` 指定一个名称。
6	指定`podSelector.matchLabels` 以选择由`namespaceSelector.matchLabels` 选择的命名空间中的 Pod 作为入口对等体。
7	ANP 同时具有入口和出口规则。`spec.egress` 字段的 ANP 规则为`action` 字段接受`Pass`、`Deny` 和`Allow` 值。

其他资源

网络策略 API 工作组

编辑

规则的 AdminNetworkPolicy 操作

作为管理员，您可以将Allow、Deny 或Pass 设置为AdminNetworkPolicy 规则的action 字段。由于 OVN-Kubernetes 使用分层 ACL 来评估网络流量规则，因此 ANP 允许您设置非常严格的策略规则，这些规则只能由管理员修改、删除规则或通过设置更高优先级的规则来覆盖。

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 对象监控，监控租户也不能决定它可以或不可以监控什么。

AdminNetworkPolicy Deny 示例

以下在优先级 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 具有较低的优先级值，使其具有更高的优先级，从而确保永远不会监控受限租户。

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 对象。此pass-monitoring ANP 允许所有在安全级别internal 下分组的租户所有者使用命名空间范围的NetworkPolicy 对象选择基础设施的监控服务是否应抓取其指标。

OVN-Kubernetes AdminNetworkPolicy