Google Cloud Platform¶
||development||selected ingresses 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.
|ekstern.dev.nav.no||internet||manually configured by adding to
|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|
|nav.no||internet||manually configured, contact at #tech-sikkerhet. URLs containing
|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
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.
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"]