关于 AdminNetworkPolicy - 网络安全 | 网络 | OpenShift Container Platform 4.17

AdminNetworkPolicy
- 规则的AdminNetworkPolicy操作

AdminNetworkPolicy

AdminNetworkPolicy (ANP) 是一个集群范围的自定义资源定义 (CRD)。作为OpenShift Container Platform管理员，您可以使用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`字段在一个集群中支持最大100个ANP，其值范围为`0-99`。值越低，优先级越高，因为该范围是从最低值到最高值按顺序读取的。由于无法保证在相同优先级下创建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