Exploring Cloud KMS Using Go Microservice Deployed on Cloud Run
By: Sundara Senthil
Tags: Cloud Kms, Go, Google Cloud Run

Exploring Cloud KMS Using Go Microservice Deployed on Cloud Run

Snapshot of this blog

This blog aims to help you understand the Cloud KMS (Key Management Service) and Cloud RUN technologies from Google. To learn these technologies, I’ve written a REST based Go microservice that we will deploy in Cloud Run and that will call into the KMS APIs. Using and deploying this microservice will enable us to compartmentalize the crypto operations from a dedicated service, let us experiment with scaling, and allow us to abstract these Google technologies from the core application.

The code can be found on GitHub: https://github.com/ssenthil416/go-samples/tree/main/kms

Let’s start by understanding what Cloud Run and Cloud KMS provides.

Cloud Run enables you to run your stateless request-driven applications in the cloud without you needing to worry about provisioning machines, cluster, or configuring auto scaling. With a single command, you can go from a “container image” to a fully managed autoscaled application running under a personal domain name with TLS support. Applications that required storing state in memory between requests isn’t a candidate for Cloud Run.

Cloud KMS allows you to create, rotate, and destroy cryptographic keys and perform cryptographic operations in a single centralized cloud service. Cloud KMS is integrated with Cloud IAM and Cloud Audit Logging so that you can manage permissions on individual keys, and monitor how these are used.

KMS package and APIs

I will now go through a few KMS APIs, which are used most commonly used in applications. The documentation for this can be found at these two links:

https://godoc.org/cloud.google.com/go/kms/apiv1

https://godoc.org/google.golang.org/genproto/googleapis/cloud/kms/v1

This is the set of KMS API’s that we will use in the service.

KMS-APIs

Go Service

The code can be found on GitHub: https://github.com/ssenthil416/go-samples/tree/main/kms

Here is the high-level structure of the project:

Packages

Files

In Go, REST based microservice can be built using the http package. A call to the http.ListenAndServer() function, which takes a URL and a port, will service traffic using the http default server mux. The application routes are registered with the default server mux using the http.Handle() function. For this service, we will register two routes, ‘/’ for health and ‘/kms’ for the kms support we are exposing.

KMS service and handler

Registering Handler with Router

The kmsapi package is used to get the KMS API client handle, which helps to call KMS APIs. The KMS client needs a project, location and credential json file, which are verified on initialization of this microservice. Each KMS request will carry a client id and key id. First time a test keyring id is passed to create the keyring id and the crypto ring. Based on the generated key ring id other operations encryption, decryption and rotation, are called accordingly.

KMS API for key ring creation

Files like Dockerfile and docker-compose are used to build and test container image locally, and finally file “cloudbuild.yaml” file is used to build container image and deploy it on Cloud Run as a stateless container service.

Couldbuild yaml for Cloud RUN

For the github code to run, we need to provide all the required info like project ID, location and credential json file. Once we have all this info, add this code to cloud source repositories. Based on Cloud RUN documents, setup CI/CD pipeline, such a way when any modification is push to cloud source repository, it will automate build and generate container image. Which then deployed to Cloud RUN. Applications or other microservice can use this Cloud RUN provided URL to handle all KMS APIs.

Sample Credential Json

Sample Use Case:

When your application wants to store a username and password to a database for future validation it can store the password with encryption using this KMS microservice. The application will call an encrypt API from KMS microservice with the generated Key Ring ID and password and store the encrypted password to the database. When validation is needed the application will call the decrypt API from the KMS microservice to decrypt and validate the user. This adds another layer of security.

Conclusion

The REST based Go microservice was written to experiment, and aid in our understanding of Cloud KMS and Cloud RUN technology, as well as a table-driven test cases to validate different KMS requests operations. I hope this blog helps you to explore and learn new technology in our services. Special thanks to Bill Kennedy Sir and Srinivasan Vanamali Sir.

References

https://cloud.google.com/kms/docs/resource-hierarchy

https://github.com/ahmetb/cloud-run-faq

https://medium.com/google-cloud/cloud-run-vs-cloud-functions-whats-the-lowest-cost-728d59345a2e

https://read.acloud.guru/the-good-and-the-bad-of-google-cloud-run-34455e673ef5

https://cloud.google.com/container-registry/docs/using-with-google-cloud-platform

https://levelup.gitconnected.com/ci-cd-pipeline-on-gcp-using-cloud-source-repository-cloud-build-container-registry-and-cloud-run-b66413133933

https://medium.com/ci-t/how-to-set-up-a-deployment-pipeline-on-gcp-with-cloud-build-container-registry-and-cloud-run-73391f5b77e4