Using Network Policies in Big Bang¶

ℹ️ NOTE: For package developers integrating network policies, see the bb-common Subchart Integration guide, which consolidates service mesh, network-policy, and authorization-policy documentation.

What are Network Policies¶

Kubernetes allows Big Bang operators to utilize Network Policies to control the network traffic into or out of the various pods of a Kubernetes cluster. These network policies allow you to restrict incoming and outgoing traffic to or from a given set of pods using selectors. Selectors allow you to select which pods a given networkPolicy will apply to.

Network Policies are added as needed to supplement other good security practices; such as proper usage of TLS, only exposing necessary ports, and using other standard controls. However, Network Policies allow you to express additional control over what can connect to the pods in your cluster from outside; which pods in your kubernetes cluster can speak to each other internally; and which things those pods can initiate connections to outside of the cluster.

Package Types and Support Levels¶

The mechanisms described in this document are natively available for:

all bigbang core packages (such as kyverno, monitoring, istio, etc)
all bigbang supported addon packages (such as minio, etc)
select community supported addons (jira, confluence)

For the purposes of this document, “customer defined package” and “community supported package” may be used interchangably and the techniques for one will apply equally to the other. However, customer defined packages will need to implement support for the networkpolicy control mechanism themselves if they want to make use of this functionality. See the bb-common Subchart Integration guide for how to implement this functionality in a customer defined package.

Enabling or Disabling Network Policies¶

BigBang core and addon packages ship with various network policies already configured. You can turn these networking policies on and off by setting a global flag and a per-component flag. Community supported packages may or may not provide the same mechanism for managing networking policies - check the documentation for the given community supported package for confirmation or additional instructions.

# This will turn support on or off for network policies writ-large across the bigbang suite
networkPolicies:
  enabled: [true|false]

# For an integrated package that consumes bb-common as a subchart, this will
# turn network policies on or off for that package. User-defined packages that
# consume bb-common as a subchart use the same nested values shape.
packages:
  LIBRARY_PACKAGE_NAME:
    values:
      bb-common:
        networkPolicies:
          enabled: [true|false]

Enabling Authorization Policies¶

AuthorizationPolicies are disabled globally by default. Enable them for integrated packages with:

istio:
  authorizationPolicies:
    enabled: true

Ambient mode enables AuthorizationPolicies regardless of this value. A package can override the generated setting beneath packages.<name>.values.istio.authorizationPolicies, or beneath packages.<name>.values.bb-common.istio.authorizationPolicies after migrating bb-common to a regular subchart.

Crafting and Delivering Additional Network Policies¶

Sometimes you will want to apply additional Network Policies to further isolate certain pods in your deployment. BigBang has adopted standardized mechanisms for crafting and deploying these Network Policies through the values provided to your BigBang core, supported addon or packages deployed with the big bang wrapper chart.

For an integrated package that consumes bb-common as a subchart, place these rules beneath that dependency’s values key:

packages:
  LIBRARY_PACKAGE_NAME:
    values:
      bb-common:
        networkPolicies:
          enabled: true
          additionalPolicies: []

User-defined packages own their internal values contract. When such a package consumes bb-common as a subchart, use the same nested shape.

In all cases, the additionalPolicies entry should be a list of YAML objects, each describing a single Network Policy. You can add as many of these as you like. Consult the upstream Kubernetes documentation for more information on Network Policies, and what you can do with them.

additionalPolicies:
  - name: example-egress-policy-all-pods
      spec:
      podSelector: {}
      policyTypes:
      - Egress
      egress:
      - to:
          - ipBlock:
              cidr: 172.20.0.0/12
  - name: example-ingress-policy-all-pods
      spec:
      podSelector: {}
      policyTypes:
      - Ingress
      ingress:
      - from:
          - ipBlock:
              cidr: 172.20.0.0/12

References¶

For more information regarding the behavior of a specific core, supported addon or community supported package, you should always reference the documentation for the specific package in question. Information specific to any given package is outside the scope of this documentation.