Using Secret Manager
1. Using Secret Manager
Finally, we discuss Secret Manager. To authenticate with other services and applications, many applications require credentials such as API keys, passwords, or certificates. These credentials must be stored securely. Developers often think about storing the credentials in flat files. Access becomes incredibly easy, but security can be difficult. Not everyone should be able to see this information, so you'd have to use the file operating system to restrict access. However, using flat files can lead to secrets being scattered across your organization's cloud and on-premises infrastructure. Secret Manager provides a secure and convenient way to store sensitive information. You can store, manage, and access secrets as binary blobs or text strings. Only users and applications with the appropriate permissions can access the secret. Keeping all of your secrets in a single place, and using IAM to determine who has access, simplifies secure management of your secrets. Now we take a quick look at some of the features of Secret Manager. The name of a secret stored in Secret Manager is global, but the secret data can optionally be stored in a specified region. Secrets can be versioned. Each version can have different secret data. There is no limit on the number of versions that can be stored. Versions cannot be modified, but they can be deleted. Secret Manager also follows the principle of least privilege. Secrets are created at the project level, and only project owners start with permission to create and access secrets within the project. Other roles must be explicitly granted IAM permissions to access secrets. When Cloud Audit Logs are enabled, every interaction with Secret Manager, including reads and updates, generates an audit entry. This auditing lets you verify that only the appropriate users and apps are accessing your secrets. Secret Manager manages server-side encryption keys on your behalf by using the same hardened key management systems used for Google's own encrypted data. Secret Manager also integrates with Cloud Key Management Service, or Cloud KMS. You can have Cloud KMS encrypt the version for a secret before storing it. After retrieving the version, Cloud KMS will also be needed to decrypt it. Next, we look at how Secret Manager works. First, we create a secret. You can use the Google Cloud console, the gcloud CLI, or code to create the secret. In this example, we create the secret by using a gcloud command. The command shown here creates a secret named "my-secret." The data file parameter takes the secret from standard input, passed in using the piped echo command. The replication policy is set to automatic, which lets the secret payload be stored in any region. A replication policy of "user-managed" lets you specify the regions where the secret might be stored. You can also retrieve secrets using the Google Cloud console, the gcloud CLI, or code. In this example, we use Python code to retrieve the secret. The Secret Manager Python SDK can be used to create, update, delete, or access secrets. The first step is to import the secretmanager library and create a client. Secrets are accessed by resource name, which includes the project ID, the ID or name of the secret, and the version you want to access. Versions are ordinal numbers: 1, 2, 3, and so on. You can also use the keyword "latest" to access the latest version for the secret. Retrieving the secret is as easy as passing the name to the library function, and decoding the payload. This process provides a secure method for using sensitive data within your applications.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.