Migrating to GCP¶
Why migrate our application(s)?¶
- Access to self-service Google-managed buckets and Postgres databases.
- Access to Google Cloud features.
- Zero Trust security model instead of FSS/SBS zone model.
- Built-in call tracing similar to AppDynamics.
- Cost efficient and future proof.
- The team needs to update their ROS and PVK analysis to migrate to GCP. Refer to Google Cloud Platform's ROS and PVK section.
- Read this roles and responsibilites
Follow the Getting started's Access from laptop instructions, and make sure to pay attention to the GCP section.
Our GCP clusters use a zero trust security model, implying that the application must specify both incoming and outgoing connections in order to receive or send traffic at all. This is expressed using the access policy spec.
The access policy also enables zone traversal and cross-cluster communication. This must be implemented in both applications, by using and accepting tokens from TokenX or AAD.
The same deployment mechanism is leveraged for both on-premise and GCP K8s clusters. See deployment section of the documentation for how to leverage the NAIS deploy tool.
See GCP clusters.
Google is cleared to be a data processor for personally identifiable information (PII) at NAV. However, before your team moves any applications or data to GCP the following steps should be taken:
- Verify that you have a valid and up-to-date PVK for your application. This document should be tech stack agnostic and as such does not need to be changed to reflect the move to GCP.
- If the application stores any data in GCP, update Behandlingskatalogen to reflect that Google is a data processor.
The ROS analysis for the team's applications need to be updated to reflect any changes in platform components used. For example, if your team has any specific measures implemented to mitigate risks related to "Kode 6 / 7 users", you should consider if these measures still apply on the new infrastructure or if you want to initiate any additional measures. When updating the ROS, please be aware that the GCP components you are most likely to use have already undergone risk assessment by the nais team and that you can refer to these ROS documents in your own risk assessment process.
Roles and responsibilites¶
As with applications in our on-premises clusters, the operation, security and integrity of any application is the responsibility of the team that owns that particular application. Conversely, it is the responsiblity of the nais platform team to handle the operation, security and integrity of the nais application platform and associated components. At GCP, Google is responsible for operating infrastructure underlying the nais platform, as well as any cloud services not consumed through the nais abstraction layer. Service exceptions reported by either Google or the nais team will be announced in the #nais slack channel.
If your application stores personally identifiable information in any GCP data store, Google is effectively a data processor ("databehandler") for this data, and your documentation needs to reflect this fact.
What do we have to change?¶
- 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
defaultnamespace, you will have to move to team namespace
- Storage: Use
s3in 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
sqlInstancein 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.
What should we change?¶
- Use TokenX instead of API-GW.
- If using automatically configured Google-managed buckets or postgres, use Google APIs
What do we not need to change?¶
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.
What can we do now to ease migration to GCP later?¶
- 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, AAD on-behalf-of or AAD client_credentials flow 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.
What about PVK?¶
A PVK is not a unique requirement for GCP, so all applications should already have one. See about security and privacy when using platform services for details
How do we migrate our database?¶
Why is there no Vault in 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 Secret Manager in each team's GCP project.
How do we migrate from Vault to Secrets Manager?¶
See the Secrets Manager documentation.
How do we migrate from filestorage to buckets?¶
Add a bucket to your application spec Copy the data from the filestore using s3cmd to the bucket using gsutil
What are the plans for cloud migration in NAV?¶
Both sbs clusters are now retired. NAVs strategic goal is to shut off all on-prem datacenters by the end of 2023
What can we do in our GCP project?¶
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
How long does it take to migrate?¶
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.
We have personally identifiable and/or sensitive data in our application, and we heard about the Privacy Shield invalidation. Can we still use GCP?¶
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.
How do I reach an application found on-premises from my application in GCP?¶
The application on-premises should generally fulfill the following requirements:
- Be secured with OAuth 2.0. That is, either:
- Exposed to GCP using a special ingress:
In cases where the application contains unsecured or endpoints secured with other mechanisms, see the "Application Requirements" section in this document.
Create a pull request at https://github.com/navikt/bigip-iac/tree/main/pub-fss add these ingresses which allows them be exposed to GCP.
The application on-premises must then:
Add the ingress created above to the list of ingresses:
If secured with OAuth 2.0, ensure that the application also has set up inbound access policies:
The application in GCP must then:
Add the above hosts to their outbound external access policies:
How do I reach an application found on GCP from my application on-premises?¶
The application in GCP must be exposed on a matching ingress:
|ingress||reachable from zone|
||internet, i.e. all clusters|
The application on-premises should not have to use webproxy to reach these ingresses.
GCP compared to on-premises¶
|Deploy||✔️||✔️||different clustername when deploying|
|Logging||✔️||✔️||different clustername in logs.adeo.no|
|Metrics||✔️||✔️||same mechanism, different datasource|
|Nais app dashboard||✔️||✔️||new and improved in GCP|
|Secure logs||✔️||✔️||different clustername in logs.adeo.no|
|Shared namespaces||✔️||✖️||Default namespace not available for teams in GCP|
|Ingress||✔️||✔️||see GCP and on-premises for available domains|
|Postgres||✔️ (IAC)||✔️ (self-service)|
|domain: dev.intern.nav.no||✔️ (Automatic)||Wildcard DNS points to GCP load balancer|
|Access to FSS services||✔️||Identical (either API-gw or TokenX. May require a proxy app, see FAQ for details.|
|PVK required||✔️||✔️||amend to cover storage in cloud|