Working with Network Policies

In a multi-tenant Kubernetes or OpenShift environment, it's crucial to ensure each tenant has the right network policies to operate securely and without interfering with other tenants. In this guide we'll walk you through using Greymatter in cooperation with network policies.

Kubernetes Network Policies

Kubernetes Network Policies are a security feature that govern how pods communicate with each other and with other network endpoints. They use labels to select pods and define rules which specify what traffic is allowed to the selected pods.

By default, a pod in Kubernetes can receive traffic from any source and send traffic to any destination. This is great for simplicity and ease of use, but from a security perspective, it's not ideal—especially in a multi-tenant production environments where different teams or applications are sharing the same Kubernetes cluster.

Best practice: create deny-all default network policy​

To ensure that all pods in the namespace are secure, a best practice is to create a default network policy. This avoids accidentally exposing an app or version that doesn’t have policy defined.

The following network policy implements a default deny-all ingress and egress policy, which prevents all traffic to/from pods in the policy-demo namespace. Note that the policy applies to all pods in the policy-demo namespace, but does not explicitly allow any traffic. All pods are selected, but because the default changes when pods are selected by a network policy, the result is: deny all ingress and egress traffic. (Unless the traffic is allowed by another network policy).

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: default-deny
  namespace: policy-demo
spec:
  podSelector:
    matchLabels: {}
  policyTypes:
    - Ingress
    - Egress

Multi-Tenant Environments

Multi-tenant environments inherently bring a higher risk of potential attack vectors. You have multiple teams, possibly multiple companies, all running workloads on the same cluster. This can lead to "noisy neighbors" where one tenant's workloads affect another's, and in the worst-case scenario, one tenant can potentially access sensitive data from another.

In such environments, Network Policies become critical to ensure that pods can only communicate with those they are supposed to. They allow administrators to enforce which network connections are allowed and can provide a level of isolation among tenants. Without Network Policies, a compromised pod could potentially establish connections to other pods, possibly leading to a larger scale security incident.

Restricting Traffic to/from Namespaces

Network Policies can be used to restrict traffic to and from namespaces, creating a boundary around the namespace and enforcing what inbound and outbound traffic is allowed. This can be particularly useful in a multi-tenant environment, where you may want to restrict traffic between namespaces to prevent tenants from interacting with each other's workloads.

For greymatter, an administrator should allow network traffic between the core-namespace and the tenant namespaces. To achieve this we need a network policy in each tenant namespace and a network policy in the core-namespace.

Here is the main network policy that will allow Greymatter to talk to any namespace via Egress for automation but restrict Ingress traffic via specific Ports.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: greymatter18-allow-ingress-from-tenants
  namespace: greymatter
spec:
  podSelector: {}
  ingress:
    - from:
        - podSelector: {}
    - ports:
        - protocol: TCP
          port: 10908
    - ports:
        - protocol: TCP
          port: 50000
        - protocol: TCP
          port: 6379
        - protocol: TCP
          port: 5555
        - protocol: TCP
          port: 8080
        - protocol: TCP
          port: 10910
      from:
        - namespaceSelector: {}
  policyTypes:
    - Ingress
status: {}

Any namespace can Ingress to Greymatter based on the specific ports. This is done on purpose so you do not have to update the policy every time you add a new NS to be managed by Greymatter’s automation.

Here is the corresponding tenant network policy. This allows Greymatter to communicate to the data planes managing tenants. You will notice that none of these policies enforce Egress, Greymatter automation includes the deployment of Spire. Spire manages which workloads are allowed to access the sidecars. If you do start to add Egress. you will need to explicitly define each Egress port for all applications.

ind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: greymatter18-tenant-allow-greymatter
  namespace: tenant-a
spec:
  podSelector: {}
  ingress:
    - from:
        - podSelector: {}
    - ports:
        - protocol: TCP
          port: 10809
        - protocol: TCP
          port: 10908
    - ports:
        - protocol: TCP
          port: 8082
        - protocol: TCP
          port: 8002
      from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: greymatter
  policyTypes:
    - Ingress
status: {}

Why Greymatter?

Greymatter solves the following use cases.

• Traffic managed by the Greymatter platform forces internal cluster traffic to go through a gateway.

• Anything TLS related.

• Protocol conversion to ensure all traffic is TLS or mTLS.

• App, API, Service or Route specific policies.

• Targeting of services by name.

• Creation or management of "Policy requests" that are fulfilled by a third party, such as an Open Policy Agent server.

• Default policies which are applied to a segment of applications, APIs, or services deployed within a cluster.

• Cross cloud or cluster policies which are applied via a policy configuration set of rules targeted at a segment of applications, APIs, or services deployed within a cluster.

• Use of GitOps without a requirement for 3rd party tooling.

• Advanced declarative definitions that can be inherited and referenced across a fleet-wide deployment across cloud or cluster.

• Advanced policy querying and reachability tooling.

• The ability to log network security events (for example connections that are blocked or accepted).

• The ability to explicitly deny policies.

• The ability to prevent loopback or incoming host traffic.

In Summary

The Kubernetes Network Policy API provides a standard way for users to define network policy for controlling network traffic. However, Kubernetes has no built-in capability to enforce the network policy.

Greymatter can enforce the policy for your applications, APIs, and services deployed within a POD. You can also add additional, more in-depth policies for traffic control, auth n/z accesses, and identity decision, enforcement, and information points.