Warning

This page was translated from the original Japanese version by PLaMo Translate. The Japanese version is authoritative; the English translation may contain inaccuracies.

Configuring Inter-Namespace Communication Controls

In PFCP, inter-namespace communication is managed according to the following policies:

Warning

Inter-Namespace Communication Policy

• All communication across Namespaces belonging to different organizations is strictly prohibited.
• By default, all communication between Namespaces within the same organization is allowed.
• Custom rejection policies can be added as needed. Communication that is already blocked by PFCP services cannot be permitted.

To implement custom rejection policies, use the CiliumNetworkPolicy custom resource^{1 2}. Below is an example demonstrating how to configure a policy to block ingress traffic from external Namespaces.

Blocking Ingress Traffic from External Namespaces Using CiliumNetworkPolicy

By creating a CiliumNetworkPolicy resource within the Namespace you wish to isolate, you can block traffic from other Namespaces. This proves particularly useful when running production workloads in a Namespace and wanting to restrict access from other Namespaces.

For example, by creating the following resource in the org-<organization-name> Namespace, only traffic originating from within the same Namespace or from the org-<organization-name>--foo Namespace will be permitted:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: "deny-except-org-<organization-name>--foo"
  namespace: "org-<organization-name>"
spec:
  endpointSelector: {}
  ingressDeny:
  - fromEndpoints:
    - matchExpressions:
      - key: k8s:io.kubernetes.pod.namespace
        operator: NotIn
        values: ["org-<organization-name>", "org-<organization-name>--foo"]

In addition to spec.ingressDeny, you can also use spec.egressDeny to block egress traffic to specific destinations. For cases where you want to prohibit outgoing traffic to particular destinations, please utilize spec.egressDeny.

Note that spec.ingress and spec.egress cannot be used. Communication with blocked destinations cannot be permitted.

Options for Blocking Ingress Traffic When Creating Sub-Namespaces

When creating or modifying sub-Namespaces through the portal interface, you can enable an option to create a CiliumNetworkPolicy that blocks all incoming traffic from other Namespaces. This feature is particularly useful for environments running production workloads where access from other Namespaces should be restricted.

This CiliumNetworkPolicy will be created with the name deny-all-ingress. After creation, you can freely modify and adjust the policy as needed.

1. Certain features of CiliumNetworkPolicy are restricted. ↩

2. For detailed documentation on CiliumNetworkPolicy, please refer to the official documentation. ↩