// Module included in the following assemblies:
//
// * networking/network_security/AdminNetworkPolicy/ovn-k-banp.adoc
// * networking/network-policy-apis.adoc

:_mod-docs-content-type: CONCEPT
[id="BaselineAdminNetworkPolicy_{context}"]
= BaselineAdminNetworkPolicy

[role="_abstract"]
To enforce `Allow` or `Deny` rules for selected namespaces in {product-title}, 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`.


[id="baselineddminnetworkpolicy-example_{context}"]
== BaselineAdminNetworkPolicy example

.Example YAML file for BANP
[source,yaml]
----
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.

[id="BaselineAdminNetworkPolicy-default-deny-example"_{context}]
== 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
[source,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:
        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`
[source,yaml]
----
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.

