---
title: OVN-Kubernetes BaselineAdminNetworkPolicy
---

# OVN-Kubernetes BaselineAdminNetworkPolicy {#ovn-k-banp}

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

## BaselineAdminNetworkPolicy {#BaselineAdminNetworkPolicy_ovn-k-banp}

To enforce `Allow` or `Deny` rules for selected namespaces in OpenShift Container Platform, 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 {#baselineddminnetworkpolicy-example_ovn-k-banp}

```yaml {title="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 {#BaselineAdminNetworkPolicy-default-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.

```yaml {title="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:

```yaml {title="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.