1. Documentation
×

OVN-Kubernetes BaselineAdminNetworkPolicy

To set cluster-wide network rules that namespace owners can override with a NetworkPolicy object, you can configure a BaselineAdminNetworkPolicy (BANP) custom resource in OKD.

BaselineAdminNetworkPolicy

To enforce Allow or Deny rules for selected namespaces in OKD, you can create a single cluster-scoped BaselineAdminNetworkPolicy custom resource (CR) named default with ingress and egress subject rules.

The BaselineAdminNetworkPolicy (BANP) CR is a cluster singleton object that can be used as a guardrail policy in case a passed traffic policy does not match any NetworkPolicy objects in the cluster. A BANP can also be used as a default security model that provides guardrails that intra-cluster traffic is blocked by default and a user will need to use NetworkPolicy objects to allow known traffic. You must use default as the name when creating a BANP resource.

A BANP allows administrators to specify:

  • A subject that consists of a set of namespaces or namespace.

  • A list of ingress rules to be applied for all ingress traffic towards the subject.

  • A list of egress rules to be applied for all egress traffic from the subject.

BaselineAdminNetworkPolicy example

Example YAML file for BANP
apiVersion: policy.networking.k8s.io/v1alpha1
kind: BaselineAdminNetworkPolicy
metadata:
  name: default
spec:
  subject:
    namespaces:
      matchLabels:
          kubernetes.io/metadata.name: example.name
  ingress:
  - name: "deny-all-ingress-from-tenant-1"
    action: "Deny"
    from:
    - pods:
        namespaceSelector:
          matchLabels:
            custom-banp: tenant-1
        podSelector:
          matchLabels:
            custom-banp: tenant-1
  egress:
  - name: "allow-all-egress-to-tenant-1"
    action: "Allow"
    to:
    - pods:
        namespaceSelector:
          matchLabels:
            custom-banp: tenant-1
        podSelector:
          matchLabels:
            custom-banp: tenant-1

where:

metadata.name

Specifies the name of the BANP resource. The policy name must be default because BANP is a singleton object.

spec.subject.namespaces.matchLabels

Specifies the namespace to apply the BANP to.

spec.ingress.name

Specifies a name for ingress rules.

spec.ingress.action

Specifies an ingress rule for the BANP. Accepts values of Deny and Allow for the action field.

spec.ingress.from.pods.namespaceSelector.matchLabels

Specifies match labels to select pods within the namespaces selected by namespaceSelector.matchLabels as ingress peers.

spec.egress.action

Specifies an egress rule for the BANP. Accepts values of Deny and Allow for the action field.

spec.egress.to.pods.namespaceSelector.matchLabels

Specifies match labels to select pods within the namespaces selected by namespaceSelector.matchLabels as egress peers.

BaselineAdminNetworkPolicy Deny example

The following BANP singleton ensures that the administrator has set up a default deny policy for all ingress monitoring traffic coming into the tenants at internal security level. When combined with the "AdminNetworkPolicy Pass example", this deny policy acts as a guardrail policy for all ingress traffic that is passed by the ANP pass-monitoring policy.

Example YAML file for a guardrail Deny rule
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:
        matchLabels:
          kubernetes.io/metadata.name: monitoring
# ...

You can use an AdminNetworkPolicy resource with a Pass value for the action field in conjunction with the BaselineAdminNetworkPolicy resource to create a multi-tenant policy. This multi-tenant policy allows one tenant to collect monitoring data on their application while simultaneously not collecting data from a second tenant.

As an administrator, if you apply both the "AdminNetworkPolicy Pass action example" and the "BaselineAdminNetwork Policy Deny example", tenants are then left with the ability to choose to create a NetworkPolicy resource that will be evaluated before the BANP.

For example, Tenant 1 can set up the following NetworkPolicy resource to monitor ingress traffic:

Example 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
# ...

In this scenario, Tenant 1’s policy would be evaluated after the "AdminNetworkPolicy Pass action example" and before the "BaselineAdminNetwork Policy Deny example", which denies all ingress monitoring traffic coming into tenants with security level internal. With Tenant 1’s NetworkPolicy object in place, they will be able to collect data on their application. Tenant 2, however, who does not have any NetworkPolicy objects in place, will not be able to collect data. As an administrator, you have not by default monitored internal tenants, but instead, you created a BANP that allows tenants to use NetworkPolicy objects to override the default behavior of your BANP.