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. 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 external addresses a workload can communicate with. This is done by defining inbound and outbound policies in the workload's manifest.

Inbound traffic¶

Allowing inbound access to your application depends on your consumers and the environment they're in:

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>]

Service discovery¶

Consumers running in the same environment should prefer to communicate with your workload via service discovery.

.spec.accessPolicy.inbound controls inbound network traffic via service discovery.

Ingress¶

To allow consumers in other environments to communicate with your workload, you should expose it with an ingress. The ingress domain controls which networks the ingress is reachable from. Other than that, inbound network traffic through an ingress is essentially unrestricted.

.spec.accessPolicy.inbound does not control network traffic via ingresses.

Outbound traffic¶

Allowing outbound traffic from your application depends on whether you're using service discovery or 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>]

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

Service discovery¶

If the service you want to call is in the same environment, you should communicate with it by using service discovery.

.spec.accessPolicy.outbound.rules controls outbound network traffic via service discovery.

External addresses¶

An external address is any address outside the environment your workload is running in. Ingresses exposed by other workloads are also considered external addresses.

.spec.accessPolicy.outbound.external controls which external addresses your workload can communicate with.

Example¶

Consider two applications: a frontend and a backend. The frontend needs to communicate with the backend by using service discovery.

This communication is denied by default as indicated by the red arrow.

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

However, the frontend is still not allowed to make any requests to the backend. The missing piece of the puzzle is an inbound policy, allowing the frontend to communicate with it:

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

Now that both applications have explicitly declared their respective inbound and outbound policies, communication is allowed.

Related pages¶

Learn how to define access policies

Learn how to communicate with other workloads via service discovery