Password rotation best practice
How to set up Google Cloud’s automatic password rotation
Although most people agree that rotating passwords is a good idea, actually putting it into practice may be difficult and disruptive. This load can be lessened by automation, and in this tutorial it provide some best practices for Google Cloud password rotation automation.
It provide a reference architecture as an illustration of how to automate the Cloud SQL instance on Google Cloud password rotation procedure. You may use this technique to other kinds of secrets and other tools as well.
Password rotation tools
Password storage on Google Cloud
It recommend utilizing Secret Manager, its fully-managed product for securely keeping secrets, even if there are numerous other options available in Google Cloud for storing secrets like passwords. Whatever tool you select, you should take extra precautions to secure stored passwords. Using Secret Manager, you can protect your secrets in the following ways:
- Restricting access: Only Service Accounts via IAM roles should be able to read or write secrets. When assigning roles to service accounts, the least privilege principle ought to be adhered to.
- Encryption: Secret Manager by default uses AES-256 to encrypt secrets while they are at rest. To secure your secrets while they’re at rest, you can also utilize your own customer-managed encryption keys (CMEK).
- Rotating passwords: To lower the chance of a security event, passwords kept in Secret Manager should be changed frequently.
Why and how to change your passwords
Changing passwords on a regular basis reduces the chance of password compromise. According to Forrester Research estimates, privileged credentials like passwords, tokens, keys, or certificates are compromised in 80% of data breaches.
Since managing passwords by hand can increase risk such as password misuse we do not advise manually rotating passwords. The possibility of human error leading to the non-performance of the rotation is another danger associated with manual rotation methods.
Including automatic password rotation in your workflow is a more safe approach. A database, an application, a third-party service, or a SaaS provider could be the source of the password.
Automatic password rotation
Usually, following actions are needed in order to rotate a password:
- In the underlying program or system (such as apps, databases, or SaaS), change the password.
- To save the new password, update Secret Manager.
- Restart any programs that require that password. By doing this, the application will obtain the most recent passwords.
Adaptable design for Automatic password rotation
Based on the best practices we just discussed, the architecture below shows a generic layout for a Google Cloud system that can rotate passwords for any underlying program or system.
The workflow should function as follows:
- A pub/sub topic receives a message from a pipeline or a cloud scheduler. The information regarding the password rotation is contained in the message. For instance, if it’s a database password, this information might be the login and database instance, or a Secret ID in Secret Manager.
- A Cloud Run Function is triggered when a message reaches the pub/sub topic. It reads the message and collects the data it contains.
- The function modifies the relevant system’s password. For instance, the function modifies the password for that user in the specified database if the message included the database instance, database name, and user.
- The function modifies the secret manager’s password to match the newly entered password. Since the Secret ID was supplied in the pub/sub message, it is aware of which one to update.
- The function notifies a different pub/sub topic by publishing a message that the password has changed. Any program or system that wants to know whether to restart itself or carry out another task in the event of a password rotation can subscribe to this topic.
