What is the Secret Manager?
With the help of this service “Secret Manager”, you secure access to your services, applications, and the resources of IT. This service empowers you to simply manage, rotate, and retrieve the credentials of the database, TLS testaments, API keys, and different secrets required by an application at runtime.
These are some of our preferred things
At the point when Google introduced its new service, we were all very excited about it! We’ve been utilizing Sops and Berglas for managing secrets as our go-to solutions. But executing those services is consistently a tedious work, so we were interested to know about the secret manager as well.
In the Pocket, we will in general go for oversaw benefits however much as could be expected. There are numerous reasons why you ought to go for oversaw administrations, yet we’ll examine them in another blog entry. A couple of our fundamental reasons is we can reduce the risk of outdated software, stay focused on the core business, security issues, wrong configuration, and also, they are immediately executed. These are great benefits.
There are numerous different solutions that are useful for overseeing secrets like Berglas or Vault. On account of Vault, a group needs to set up and deal with the entire framework. This implies more time and more budget for overseeing something that should be done for you. On the other hand, Berglas offers secret management through Google Cloud KMS. In case you’re as of now working with Berglas, you can simply incorporate it with Google Secret Manager. However, when beginning a new project, you should simply execute Google Secret Manager from the omit Berglas and get-go altogether, as adding Berglas provides no additional benefits to the integration.
The way Google Secret Manager is built into the program is completely up to you. You could see it as a service that is completely decoupled where you manage everything yourself.Another solution is to connect it with the deployed system, where secret versions can be generated while the application is being developed and deployed.A secret could be a binary blob or text string, so it could hold the value for one secret or a whole JSON file containing all of the application’s secrets. How many secrets you will use will rely on what permissions and your personal preference are needed.
Secure access to your secrets
Google Secret Manager uses the principle of least privilege. By default, only project owners have permission to access any secret. Access control is provided via Cloud IAM where you can give access to other members to read & admin and ensure they have the access rights they truly require. Individual secrets can be granted permissions too and can be easily disabled.
In Google Cloud, a major benefit of keeping your secrets is that not everybody has access to them. You first need access to the Google Cloud portal and additionally, you need permissions to view or control secrets. Secrets could hold data that provide somebody accesses to database, service, … what’s more, those could hold a great deal of important data. When building up an application that works with medical information, you don’t need everybody from your company to approach it. The Secret Manager and Google Cloud cause you to prevent that! So this is a major success! Getting Google Cloud certification will further clarify the use of Secret Manager.
What more, another big advantage is that when Cloud Audit Logging is enabled, audit logging comes for free. An audit entry will be made for each interaction with the Secret Manager. This could assist you in identifying potential security leaks and abnormal access.
Thereason forencrypted secrets importance
A normal approach for infusing secrets and configuration is the utilization of environmental factors. More or less every application, platform, or service is capable to read an environment variable. This approach is very straightforward and easy, but it has one significant problem: The secrets exist in a plaintext environment.
Some other procedures, dependency, library in your environment approaches to the environment variables. A malicious library could lead to considerable security leakage. Environment variables are wonderful but not secrets for storing configuration settings!
Our secrets are stored in a central location with the help of Google’s Secret Manager, which is encrypted by default that is only reachable if you have the access permission. Here the encrypted part is one of the most significant: secrets are secured by moving them to and from Google Cloud when they are at rest, and also when they are in transit. The Secret Manager supports both Customer-oversaw encryption keys (CMEKs) and Google-oversaw encryption keys (GMEKs) when at rest.
Each secret data is unchangeable then you’re obligated to create a new version whenever the secret changes the content. You can access a secret from a particular version from within your application, or get the newest version with the ‘latest’ alias. Google recommends that the new update cannot be used in development and testing and that a different production update should be used.
A significant benefit of versioned secrets is that it helps a steady rollout of your application’s new version or that you’re ready to do a rollback when something turns out badly.
Easy peasy integration
We created a proof of concept (POC) after Google launched its Secret Manager to see how much work it takes to implement their new project. For this POC we used to manage configuration using Cloud Run, Fastify as our Node.js framework, and Node Config.
With our secret (e.g. ORM Config) that is stored in the Google Secret Manager, we extended the configuration. First, we formed a script that interacts with Secret Manager at Google. You’re probably wondering where the credentials should be accessing the service. Service IAM access is provided where App Software has the right to view information.
When Google announced the creation of a POC by their secret manager to test this new program first. We were always impressed at the smoothness of the integration and especially when you equate it to alternatives like Vault or Berglas. It really integrates well with all of the other offerings we use within Google Cloud (Cloud Run, Kubernetes, data security …), so that we can only advise to using the Google Cloud Secret Manager!