Parameters

The parent key for all of the following parameters is networkpolicy.

labels

type

dictionary
default 
noDefaults: network-policies.syn.tools/no-defaults
policySetPrefix: set.network-policies.syn.tools/
## Deprecated
# Use `base` policy set instead. e.g. `set.network-policies.syn.tools/base: ""`
baseDefaults: network-policies.syn.tools/base-defaults
## Deprecated and unused. Here for backwards compatibility as some components still include this label
purgeDefaults: network-policies.syn.tools/purge-defaults
purgeNonBase: network-policies.syn.tools/purge-non-base

Name of the labels to be used in other components.

By default, two sets of policies are created in every namespace: - base policies, which are required for the platform to function correctly. - default policies, which allow pods in the same namespace to communicate with each other. The default policies can be modified with the labels defined in this parameter.

policySetPrefix label prefix

Custom policy sets can be applied to a namespace by adding a label with this prefix and the name of the policy set as suffix. For example, to apply the ingress policy set, add the label set.network-policies.syn.tools/ingress: "" to the namespace. The label value is ignored and can be an empty string.

As soon as any policy set label is applied to a namespace, the default policy set is removed unless it is explicitly added again using the corresponding label.

noDefaults label

Policies will no longer be managed and existing policies managed by this component will be removed in namespaces with this label.

baseDefaults label

This label is deprecated. Use the set.network-policies.syn.tools/base: "" label instead.

Only policies required for the OpenShift platform will be created. The intra-namespace policy will be removed and the pods in the namespace will be isolated from each other.

purgeDefaults and purgeNonBase labels

Unused and have no effect. Purging of policies is the default behavior and can’t be disabled.

basePolicy.allowNamespaceLabels

type

dictionary[string](list of tuples|tuples|null)
default

{}
example 
allowNamespaceLabels:
  mylabel:
    - test.example.net/test-group: group1
    - test.example.net/test-group: group2
  myOtherLabel:
    test.example.net/ingress-group: "group1"
    test.example.net/ingress-group: "group2"
  myThirdLabel: null

The key is for easier merging in commodore and has no semantic meaning. The value is either a list of tuples, a single tuple or null. The values are a list of labels matching namespaces to allow traffic from. Each list item can contain several key value pairs. They result in an AND condition. Individual list items will result in an OR condition.

In the above example, traffic will be allowed if a namespaces has the label test.example.net/test-group=group1 OR test.example.net/test-group=group2. Traffic will also be allowed if a namespace has the label test.example.net/ingress-group=group1 AND test.example.net/ingress-group=group2.

ignoredNamespaces

type

list of strings
default

empty list

A list of namespace names where no default NetworkPolicies will be created. Default NetworkPolicies will be purged for all namespaces in this list. Entries in the list can be removed by adding the entry prefixed with a ~.

basePolicy.cniPlugins.cilium.allowFromNodeLabels

type

dict
default

{}

This parameter allows users to customize the allow-from-cluster-nodes CiliumNetworkPolicy.

When this parameter is empty, this policy allow access from workloads running on all cluster nodes (including nodes of other clusters in the same cluster mesh) to workloads. This ensures that — for example — an ingress controller which is running in host-network mode can access workloads that are exposed through an Ingress.

When the parameter isn’t empty, the component uses the contents as the value for matchLabels in a fromNodes entry in the CiliumNetworkPolicy. This restricts access to workloads to the host network on nodes matching the provided label selector(s). See the Cilium documentation for details on the fromNodes policy mechanism.

When setting a value for this parameter, you must ensure that you’re using Cilium 1.16 or newer and that the Helm value nodeSelectorLabels=true is set for your Cilium installation.

The allow-from-cluster-nodes policy always allows access to workloads in the namespace from the host on which they’re running. This ensures that the Kubernetes health checks work as expected regardless of the provided label selector.

For isolating access to workloads between clusters in a Cilium cluster mesh, you can label all nodes of each cluster with the cluster’s Project Syn ID, for example with kubectl label nodes --all syn.tools/cluster-id=c-the-cluster-1234.

Then you can set this parameter as

allowFromNodeLabels:
  syn.tools/cluster-id: ${cluster:name}

policies

type

dict
default

{}

Define additional NetworkPolicies or CiliumNetworkPolicies to be used by policy sets.

Make sure to use the prefix cilium/ when defining CiliumNetworkPolicies.

Also see Using and customizing policies.

policySets

type

dict
default

{}

Define policy sets that can be selected by the label network-policies.syn.tools/policy-sets. A policy set is an array of policy names defined in policies. Names can be removed from the default policy sets by prefixing them with a ~. A policy can be part of multiple policy sets, even if those policy sets are applied to the same namespace.

Also see Using and customizing policies.

Example

# Allow traffic from ingress and monitoring
basePolicy:
  allowNamespaceLabels:
    monitoring:
      - network.openshift.io/policy-group: monitoring
    ingress:
      - network.openshift.io/policy-group: ingress
# Do not create the default policies in the OpenShift namespaces.
ignoredNamespaces:
  - openshift
  - openshift-apiserver
  - openshift-apiserver-operator
  - …