Exploring Cloud KMS Using Go Microservice Deployed on Cloud Run
Written by Sundara Senthil, Edited by Angelica Hill
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.
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.
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.
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.
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 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
