Migrating to GCP¶

• Cluster name: All references to cluster name. (Logs, grafana, deploy, etc.)
• Secrets: are now stored as native secrets in the cluster, rather than externally in Vault.
• Namespace: If your application is in the default namespace, you will have to move to team namespace
• Storage: Use GCS-buckets instead of s3 in GCP. Buckets, and access to them, are expressed in your application manifest
• Ingress: There are some domains that are available both on-prem and in GCP, but some differ, make sure to verify before you move.

• Postgres: A new database (and access to it) is automatically configured when expressing sqlInstance in your application manifest

  We're currently investigating the possibility of using on-prem databases during a migration window.

• PVK: Update your existing PVK to include cloud

GCP compared to on-premises summarizes the differences and how that may apply to your application.

• Use TokenX instead of API-GW.
• If using automatically configured Google-managed buckets, use Google APIs

You do not have to make any changes to your application code. Ingresses work the same way, although some domains overlap and others are exclusive. Logging, secure logging, metrics and alerts work the same way.

• Make sure your PVK is up to date.
• Deploy your application to your team's namespace instead of default, as this is not available in GCP.
• Use a token auth flow between your applications. Either TokenX or Entra ID depending on your use case. This allows for a more seamless migration of your applications. E.g. if you have two apps in FSS, you can migrate one without the other.

See Migrating databases to GCP.

There is native functionality in GCP that overlap with many of the use cases that Vault have covered on-prem. Using these mechanisms removes the need to deal with these secrets at all. Introducing team namespaces allows the teams to manage their own secrets in their own namespaces without the need for IAC and manual routines. For other secrets that are not used by the application during runtime, you can use the Secrets in Console.

See the Secrets documentation.

Add a bucket to your application spec Copy the data from the filestore using s3cmd to the bucket using gsutil

Both sbs clusters are now retired. NAVs strategic goal is to shut off all on-prem datacenters by the end of 2023

The teams GCP projects are primarily used for automatically generated resources (buckets and postgres). We're working on extending the service offering. However, additional access may be granted if required by the team

A minimal application without any external requirements only have to change a single configuration parameter when deploying and have migrated their application in 5 minutes. GCP compared to on-premises summarizes the differences and how that may apply to your application.

Yes. NAV's evaluation of our Data Processor Agreement with Google post-Schrems II is that it still protects us and is valid for use given that data is stored and processed in data centers located within the EU/EEA. If your team uses resources provisioned through NAIS, this is guaranteed by the nais team. If your team uses any other GCP services the team is responsible for ensuring that only resources within EU/EES are used (as well as for evaluating the risk of using these services).

See Laws and regulations/Application PVK for details.

The application on-premises should generally fulfill the following requirements:

1. Be secured with OAuth 2.0. That is, either:
   • a. TokenX, or
   • b. Entra ID
2. Exposed to GCP using a special ingress:
   • https://<app>.dev-fss-pub.nais.io
   • https://<app>.prod-fss-pub.nais.io

The application on-premises must then:

1. Add the ingress created above to the list of ingresses:

   spec:
     ingresses:
       - https://<app>.<dev|prod>-fss-pub.nais.io
   

2. If secured with OAuth 2.0, ensure that the application also has set up inbound access policies:

   • a. Access Policies for TokenX
   • b. Access Policies for Entra ID)

The application in GCP must then:

1. Add the above hosts to their outbound external access policies:

   spec:
     accessPolicy:
       outbound:
         external:
           - host: <app>.<dev|prod>-fss-pub.nais.io
   

2. Consume the application using the special ingress. Other ingresses are not reachable from GCP.

The application in GCP must be exposed on a matching ingress:

The application on-premises should not have to use webproxy to reach these ingresses.