Skip to content

Google Cloud Platform

cluster environment comment
dev-gcp development selected ingresses publicly accessible
prod-gcp production publicly accessible
labs-gcp development publicly accessible

In GCP, we do not operate with a zone model like with the on-premise clusters. Instead, we rely on a zero trust model with a service mesh. The only thing we differentiate on a cluster level is development and production.

The applications running in GCP need access policy rules defined for every other service they receive requests from or sends requests to.

To access the GCP clusters, see Access.


With the ability to grant permissions, the team has full control of the team's GCP projects, and should take care when granting further permissions or enabling features and APIs.

Accessing the application

Access is controlled in part by ingresses, which define where your application will be exposed as a HTTP endpoint. You can control where your application is reachable from by selecting the appropriate ingress domain.


Make sure you understand where you expose your application, taking into account the state of your application, what kind of data it exposes and how it is secured. If in doubt, ask in #nais or someone on the NAIS team.

You can control from where you application is reachable by selecting the appropriate ingress domain. If no ingress is selected, the application will not be reachable from outside the cluster.

dev-gcp ingresses

domain accessible from description internet manually configured by adding to external_domains in load balancer config and making a pull request. URLs containing /metrics, /actuator or /internal are blocked naisdevice development ingress for applications naisdevice development ingress for non-public/internet-facing applications naisdevice reserved for platform services deprecated replaced by

prod-gcp ingresses

domain accessible from description internet manually configured, contact at #tech-sikkerhet. URLs containing /metrics, /actuator or /internal are blocked naisdevice used by non-public/internet-facing applications (previously called naisdevice reserved for platform services

More info about how DNS is configured for these domains can be found here

labs-gcp ingresses

domain accessible from description internet automatically configured


When establishing an application on GCP, it is a great time to update its Risikovurdering (ROS) analysis. It is required to update the application's entry in the Behandlingsoversikt when changing platforms. If both of these words are unfamiliar to your team, it's time to sit down and take a look at both of them.

Every application needs to have a ROS analysis. Applications handling personal information needs a Personvernkonsekvens (PVK) analysis and an entry in the Behandlingsoversikt.

See also additional information about ROS and PVK under Laws and regulations.

Questions about ROS can be directed to Leif Tore Løvmo, while Line Langlo Spongsveen can answer questions about PVK and Behandlingsoversikt.

Starting application when Istio proxy is ready

In GCP, all pods gets Istio proxy injected as a sidecar. All traffic to and from the application container will be routed through this proxy, and it is therefore essential that this container is running. If the application attempts communication before the Istio proxy is ready, it will result in an error situation. To avoid this, you can add a wrapper application called scuttle around your application executable in your container, which will ensure that Istio proxy is ready before your application executable starts. Scuttle also ensures that Istio proxy is terminated when the application exits. This is particularly useful when running jobs.

Add the following to your Dockerfile:

COPY --from=redboxoss/scuttle:latest /scuttle /bin/scuttle
ENTRYPOINT ["scuttle", "node", "index.js"]