mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
133 lines
5.2 KiB
Plaintext
133 lines
5.2 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * networking/network-policy-apis.adoc
|
|
|
|
:_mod-docs-content-type: CONCEPT
|
|
[id="BaselineAdminNetworkPolicy"_{context}"]
|
|
= BaselineAdminNetworkPolicy
|
|
|
|
`BaselineAdminNetworkPolicy` (BANP) is a cluster-scoped custom resource definition (CRD). As a {product-title} administrator, you can use BANP to setup and enforce optional baseline network policy rules that are overridable by users using `NetworkPolicy` objects if need be. Rule actions for BANP are `allow` or `deny`.
|
|
|
|
The `BaselineAdminNetworkPolicy` resource is a cluster singleton object that can be used as a guardrail policy incase 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
|
|
[%collapsible]
|
|
====
|
|
[source,yaml]
|
|
----
|
|
apiVersion: policy.networking.k8s.io/v1alpha1
|
|
kind: BaselineAdminNetworkPolicy
|
|
metadata:
|
|
name: default <1>
|
|
spec:
|
|
subject:
|
|
namespaces:
|
|
matchLabels:
|
|
kubernetes.io/metadata.name: example.name <2>
|
|
ingress: <3>
|
|
- name: "deny-all-ingress-from-tenant-1" <4>
|
|
action: "Deny"
|
|
from:
|
|
- pods:
|
|
namespaceSelector:
|
|
matchLabels:
|
|
custom-banp: tenant-1 <5>
|
|
podSelector:
|
|
matchLabels:
|
|
custom-banp: tenant-1 <6>
|
|
egress:
|
|
- name: "allow-all-egress-to-tenant-1"
|
|
action: "Allow"
|
|
to:
|
|
- pods:
|
|
namespaceSelector:
|
|
matchLabels:
|
|
custom-banp: tenant-1
|
|
podSelector:
|
|
matchLabels:
|
|
custom-banp: tenant-1
|
|
----
|
|
<1> The policy name must be `default` because BANP is a singleton object.
|
|
<2> Specify the namespace to apply the ANP to.
|
|
<3> BANP have both ingress and egress rules. BANP rules for `spec.ingress` and `spec.egress` fields accepts values of `Deny` and `Allow` for the `action` field.
|
|
<4> Specify a name for the `ingress.name`
|
|
<5> Specify the namespaces to select the pods from to apply the BANP resource.
|
|
<6> Specify `podSelector.matchLabels` name of the pods to apply the BANP resource.
|
|
====
|
|
|
|
|
|
|
|
[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
|
|
[%collapsible]
|
|
====
|
|
[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`
|
|
[%collapsible]
|
|
====
|
|
[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.
|
|
|