Skip to content

Zero Trust

NAIS embraces the zero trust security model, where the core principle is to "never trust, always verify".

In NAIS, every workload is isolated by default. This means that workloads are not able to make any outbound requests or receive any incoming traffic unless explicitly allowed.

We use access policies to specify which applications and services a workload can communicate with. This is done by defining inbound and outbound policies in the workload's manifest.

Access policies only restrict network traffic for workloads running in the GCP environments. They do not affect network traffic in the on-premise environments.

Inbound traffic

Depending on your use case and environment, you can allow inbound access in multiple ways:

graph TD
  A[Are your consumers in the same environment?]
  A --> |Yes| B[Are they in the same namespace?]
  A --> |No| Ingress[🎯 <a href='../../application/how-to/expose'>Expose through ingress</a>]
  B --> |Yes| InternalSameNS[🎯 <a href='../../how-to/access-policies#receive-requests-from-workloads-in-the-same-namespace'>Allow access in same namespace</a>]
  B --> |No| InternalOtherNS[🎯 <a href='../../how-to/access-policies#receive-requests-from-workloads-in-other-namespaces'>Allow access from other namespaces</a>]

Inbound policies defined in .spec.accessPolicy.inbound are:

  • enforced for consumers in the same environment using service discovery.

  • not enforced for traffic through an ingress.

  • enforced for authorizing consumers using Entra ID or TokenX regardless of environment.

Inbound policies do not affect ingress traffic. An ingress exposes your application to a selected audience, depending on the domain. All traffic through an ingress is implicitly allowed. Your workload is thus responsible for authorizing requests if exposed through an ingress.

Outbound traffic

Outbound traffic can be allowed to either other workloads in the same environment as well as external addresses:

graph TD
  A[Is the service you want to call in the same environment?]
  A --> |Yes| B[Are they in the same namespace?]
  A --> |No| Internet[🎯 <a href='../../how-to/access-policies#send-requests-to-external-addresses'>Allow access to external address</a>]
  B --> |Yes| InternalSameNS[🎯 <a href='../../how-to/access-policies#send-requests-to-another-app-in-the-same-namespace'>Allow access to same namespace</a>]
  B --> |No| InternalOtherNS[🎯 <a href='../../how-to/access-policies#send-requests-to-other-app-in-another-namespace'>Allow access to other namespaces</a>]

Outbound policies defined in .spec.accessPolicy.outbound are:

Ingresses are external addresses. We recommend using service discovery to communicate with other workloads when possible.

Services offered by NAIS (such as databases) are automatically configured with necessary access policies.

Example

Consider a simple application which consists of a frontend and a backend, where naturally the frontend needs to communicate with the backend.

This communication is denied by default as indicated by the red arrow. access-policy-1

In order to fix this, the frontend needs to allow outbound traffic to the backend by adding the following access policy.

spec:
  accessPolicy:
    outbound:
      rules:
        - application: backend

access-policy-2

However - the frontend is still not allowed to make any requests to the backend. The missing piece of the puzzle is adding an inbound policy to the backend like so:

spec:
  accessPolicy:
    inbound:
      rules:
        - application: frontend

access-policy-3

Now that both applications has explicitly declared their policies, the communication is allowed.

🎯 Learn how to define access policies

🎯 Learn how to communicate with other workloads within an environment