Network

:toc:-title: In this section:

Network isolation

Every SD Elements component can be configured to filter out unauthorized network communications. This is accomplished by utilizing NetworkPolicy resources that Helm automatically generates when the global.networkIsolation option is set to a value other than its default (none).

Requirements

This feature requires Container Network Interface (CNI) providers such as Cilium for Kubernetes, and OVN-Kubernetes for OpenShift. OpenShift SDN is also supported for namespace and ingress network isolation levels.

Acceptable values for global.networkIsolation

  • none: disables this feature, allowing each pod to freely communicate with all other pods and resources located within or outside the cluster.

  • namespace: permits pod-to-pod communication within the current Kubernetes namespace while blocking most communications initiated by pods and resources in other namespaces. All outbound traffic is permitted.

  • ingress: each component can only receive network connections from pods and resources that have been expressly authorized. All outbound traffic is permitted. We feel that this option provides the ideal balance between security and usability, as customers may utilize the default ruleset without performing extensive tuning, and the likelihood of lateral movement in the event of a compromise is significantly reduced.

  • full: SDE components can only establish network connections with pods and resources that have been expressly authorized. By default, all outbound traffic is prohibited. Substantial tuning is required for this choice, which may necessitate the assistance of the SDE Support group.

Configuration examples

Add one of the following configurations to an overlay (e.g. values.custom.yaml) file according to the desired security level.

Disable network isolation

global:
  networkIsolation: "none"

Enable ingress-level network isolation

global:
  networkIsolation: "ingress"

Additional rules

When global.networkIsolation is set to either ingress or full, extra rules may be required to facilitate connections between pods that are not ordinarily supposed to exchange data.

In this example, we will add a rule to allow NGINX ingress pods with label app.kubernetes.io/name: ingress-nginx from the Kubernetes namespace ingress-nginx to access the MinIO console UI on port 9001. To accomplish this, we will copy the networkPolicy section that refers to MinIO and all its rules from values.yaml to values.custom.yaml. After that, we will simply append a new selectors block like the following one:

networkPolicies:
  minio:
    podSelector:
      matchLabels:
        app: minio
    ingress:
      - selectors:
        ...omitted for brevity...
      - selectors:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: "ingress-nginx"
          podSelector:
            matchLabels:
              app.kubernetes.io/name: ingress-nginx
        ports:
          - port: '9001'

Once applied this configuration, we can run kubectl get netpol -o custom-columns=:metadata.name | grep np-minio | xargs kubectl get netpol -o yaml, to see the changes reflected into MinIO’s NetworkPolicy. Specifically, the following block should appear:

  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: ingress-nginx
      podSelector:
        matchLabels:
          app.kubernetes.io/name: ingress-nginx
    ports:
    - port: 9001
      protocol: TCP

IPv6 support

IPv6 is the most recent version of the Internet Protocol. It offers several improvements over IPv4, including a larger address space, and greater scalability and network efficiency in Kubernetes.

SD Elements can be configured to work with standard IPv4 addressing (default), or IPv6-only fashion by tuning the value for global.ipFamilies. Although it is possible to use SD Elements in a dual-stack (IPv4 + IPv6) configuration, this mode is unsupported and its adoption is discouraged due to the increased infrastructure network complexity.

Requirements

This feature requires an IPv6-enabled Kubernetes version greater than or equal to 1.24.

If the Kubernetes cluster is not configured to use NAT64 and DNS64, external addresses that don’t expose IPv6 endpoints will be unreachable.

Configuration examples

By default, SD Elements runs in IPv4-only mode. To configure it to run in IPv6-only mode, add the following configuration to an overlay (e.g. values.custom.yaml).

General IPv6-only configuration

global:
  ipFamilies:
    - IPv6

In addition, it may be necessary to adjust the configurations of other components, as discussed in the following sections.

Nginx Ingress controller configuration

When using a dedicated Nginx ingress controller, it is also needed to report the IPv6 value in ingress-nginx.controller.service.ipFamilies.

ingress-nginx:
  enabled: true
  controller:
    service:
      ipFamilies:
        - IPv6

Example with all the IPv6 configurations above

global:
  ipFamilies:
    - IPv6
  sharedStorage:
    s3Url: https://s3.dualstack.us-east-1.amazonaws.com
    ...

sc-mail:
  config:
    relayNetworks: "fd00:c00b:1::/112"

ingress-nginx:
  controller:
    service:
      ipFamilies:
      - IPv6
  ...

Mailer service configuration

When using an external service to complete the message delivery, it is necessary to verify that its endpoint is also reachable via IPv6.

The configuration for the SD Elements mailer needs to be also adjusted to enable it to relay messages for the cluster’s CIDR thus ensuring that notifications are correctly relayed. In the following snippet of code, we assume that fd00:c00b:1::/112 is the cluster’s IPv6 CIDR for our Kubernetes installation:

sc-mail:
  config:
    relayNetworks: "fd00:c00b:1::/112"

IP Whitelisting

IP whitelisting can be configured with by setting specific list of IPs under global.nginxIngress.ipWhitelists, these lists can be named for clarity. for example:

global:
  nginxIngress:
    ipWhitelistEnabled: false
    ipWhitelists:
      vpn: "1.2.3.4,5.6.7.8"
      developement: "8.7.6.5/32,4.3.2.1/32"

Service mesh (Istio)

SD Elements can run inside an Istio service mesh. Set global.istio.enabled to true to enable it. This generates the mesh resources (a DestinationRule, and a VirtualService when a host is provided).

Prerequisites

The chart generates only the routing resources. Ensure the following are in place first:

  • Istio installed in the cluster.

  • Sidecar injection enabled on the SD Elements namespace (label istio-injection=enabled).

  • A Gateway resource and its TLS Secret. The chart does not create the Gateway; istio.gateways must reference one that already exists.

apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: sde-gateway
  namespace: istio-system
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 443
        name: https
        protocol: HTTPS
      tls:
        mode: SIMPLE
        credentialName: sde-tls   # Secret holding the listener certificate
      hosts:
        - sde.example.com

Enable the mesh

Add the following configuration to an overlay (e.g. values.custom.yaml).

global:
  istio:
    enabled: true

Route traffic through a gateway

global.istio.enabled generates the DestinationRule but not the routing. To publish a VirtualService, set the host and gateways under istio.

global:
  istio:
    enabled: true

istio:
  host: sde.example.com
  gateways:
    - istio-system/sde-gateway

MCP server routing

When the MCP server is enabled, it is published at /mcp on the SD Elements host.

This route requires istio.host to be set.

Add the MCP server to the configuration above.

sde-mcp:
  enabled: true

Envoy GatewayAPI

SD Elements supports Kubernetes Gateway API routing via Envoy Gateway. When enabled, the chart creates an HTTPRoute that attaches to an existing Gateway resource. Optionally, it can also create a BackendTLSPolicy between the gateway and the backend, an HTTP-to-HTTPS redirect route, a ReferenceGrant for cross-namespace secret access, a RabbitMQ management console route, and custom endpoint routes with optional IP restrictions.

Prerequisites

  • Kubernetes Gateway API CRDs installed in the cluster.

  • An Envoy Gateway (or compatible implementation) deployed and running.

  • A Gateway resource exists and is ready. The chart attaches an HTTPRoute to it but does not create the Gateway itself.

Enable Gateway API routing

Set gatewayAPI.enabled to true and provide the name of the existing Gateway resource.

gatewayAPI:
  enabled: true
  gatewayName: public-gateway       # required — name of the Gateway to attach to
  gatewayNamespace: gateway-system  # optional — defaults to the release namespace
  sectionName: https                # optional — listener section name on the Gateway

Backend TLS

To enable TLS verification for traffic from the gateway to the SD Elements backend, configure backendTLS.caCertificateRef with the Secret or ConfigMap that holds the CA certificate. This creates a BackendTLSPolicy.

gatewayAPI:
  enabled: true
  gatewayName: public-gateway
  backendTLS:
    caCertificateRef:
      - name: sde-backend-ca
        kind: Secret   # Secret (default) or ConfigMap

To provision the CA certificate as a Kubernetes Secret directly from PEM values, use customTlsCertificate:

customTlsCertificate:
  enabled: true
  secretName: sde-backend-ca
  tlsCertificate: |-
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
  tlsKey: |-
    -----BEGIN PRIVATE KEY-----
    ...
    -----END PRIVATE KEY-----
  caCertificate: |-          # optional
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----

The secret name defaults to <release>-custom-tls-certificate and can be referenced in gatewayAPI.backendTLS.caCertificateRef.

results matching ""

    No results matching ""