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.
Warning
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.
Warning
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 |
---|---|---|
ekstern.dev.nav.no | 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 |
dev.nav.no | naisdevice | development ingress for nav.no applications |
dev.intern.nav.no | naisdevice | development ingress for non-public/internet-facing applications |
dev-gcp.nais.io | naisdevice | reserved for platform services |
deprecated replaced by dev.intern.nav.no |
prod-gcp ingresses¶
domain | accessible from | description |
---|---|---|
nav.no | internet | manually configured, contact at #tech-sikkerhet. URLs containing /metrics , /actuator or /internal are blocked |
intern.nav.no | naisdevice | used by non-public/internet-facing applications (previously called adeo.no). |
prod-gcp.nais.io | 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 |
---|---|---|
labs.nais.io | internet | automatically configured |
ROS and PVK¶
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
ENV ENVOY_ADMIN_API=http://127.0.0.1:15000
ENV ISTIO_QUIT_API=http://127.0.0.1:15020
ENTRYPOINT ["scuttle", "node", "index.js"]