26 lines
16 KiB
JSON
26 lines
16 KiB
JSON
{
|
|
"schema_version": 1,
|
|
"saved_at": "2026-08-07T05:23:49.3089789Z",
|
|
"content_sha256": "e01e788fe3acede7492bc2c0a145872fd5abda43a8eedd3eed024b12df1899bc",
|
|
"result": {
|
|
"title": "Overview - Platform Engineering on Google Cloud",
|
|
"url": "https://googlecloudplatform.github.io/platform-engineering/reference-architectures/automated-password-rotation/",
|
|
"snippet": "Manual rotation processes also introduce the risk that the rotation isn't actually performed due to human error, for example forgetting or typos. This necessitates having a workflow that automates password rotation. The password could be of an application, a database, a third-party service or a SaaS vendor etc.",
|
|
"content": "Automated password rotation\n\nExample deployment for automatic password rotation in CloudSQL\n\nReview the deployed architecture\n\nRotate the Cloud SQL password\n\nTest the new password\n\nConclusion\n\nBackstage\n\nCloud deploy flow\n\ncloudDeployInteractions\n\ncloudDeployOperations\n\ncreateRelease\n\nCloudRun\n\nWebsiteDemo\n\nGithub runners gke\n\nSandboxes\n\nGcp sandboxes\n\nSandbox modules\n\nExample deployment for automatic password rotation in CloudSQL\n\nReview the deployed architecture\n\nRotate the Cloud SQL password\n\nTest the new password\n\nConclusion\n\nOverview ¶\n\nSecrets rotation is a broadly accepted best practice across the information\ntechnology industry. However, often times it is cumbersome and disruptive\nprocess. In this guide you will use Google Cloud tools to automate the process\nof rotating passwords for a Cloud SQL instance. This method could easily be\nextended to other tools and types of secrets.\n\nStoring passwords in Google Cloud ¶\n\nIn Google Cloud, secrets including passwords can be stored using many different\ntools including common open source tools such as Vault , however in this\nguide, you will use Secret Manager , Google Cloud's fully\nmanaged product for securely storing secrets. Regardless of the tool you use,\npasswords stored should be further secured. When using Secret\nManager , following are some of the ways you can further secure\nyour secrets:\n\nLimiting access : The secrets should be readable writable only through\nthe Service Accounts via IAM roles . The principle\nof least privilege must be followed while granting roles to the service\naccounts.\n\nEncryption : The secrets should be encrypted. Secret\nManager encrypts the secret at rest using AES-256 by\ndefault. But you can use your own encryption keys, customer-managed\nencryption keys (CMEK) to encrypt your secret at rest. For details, see\nEnable customer-managed encryption keys for Secret\nManager .\n\nPassword rotation : The passwords stored in the secret manager should be\nrotated on a regular basis to reduce the risk of a security incident.\n\nWhy password rotation ¶\n\nSecurity best practices require us to regularly rotate the passwords in our\nstack. Changing the password mitigates the risk in the event where passwords are\ncompromised.\n\nHow to rotate passwords ¶\n\nManually rotating the passwords is an antipattern and should not be done as it\nexposes the password to the human rotating it and may result in security and\nsystem incidents. Manual rotation processes also introduce the risk that the\nrotation isn't actually performed due to human error, for example forgetting or\ntypos.\n\nThis necessitates having a workflow that automates password rotation. The\npassword could be of an application, a database, a third-party service or a SaaS\nvendor etc.\n\nAutomatic password rotation ¶\n\nTypically, rotating a password requires these steps:\n\nChange the password in the underlying software or system\n\n(such as applications,databases, SaaS).\n\nUpdate Secret Manager to store the new password.\n\nRestart the applications that use that password. This will make the\n\napplication source the latest passwords.\n\nThe following architecture represents a general design for a systems that can\nrotate password for any underlying software/system.\n\nWorkflow ¶\n\nA pipeline or a cloud scheduler job sends a message to a\npub/sub topic. The message contains the information about the password that is\nto be rotated. For example, this information may include secret ID in secret\nmanager, database instance and username if it is a database password.\n\nThe message arriving to the pub/sub topic triggers a Cloud Run\nFunction that reads the message and gathers information as\nsupplied in the message.\n\nThe function changes the password in the corresponding system. For example, if\nthe message contained a database instance, database name and user,the function\nchanges the password for that user in the given database.\n\nThe function updates the password in secret manager to reflect the new\npassword. It knows what secret ID to update since it was provided in the\npub/sub message.\n\nThe function publishes a message to a different pub/sub topic indicating that\nthe password has been rotated. This topic can be subscribed any application or\nsystem that may want to know in the event of password rotation, whether to\nre-start themselves or perform any other task.\n\nExample deployment for automatic password rotation in CloudSQL ¶\n\nThe following architecture demonstrates a way to automatically rotate CloudSQL\npassword.\n\nWorkflow of the example deployment ¶\n\nA Cloud Scheduler job is scheduled to run every 1st day on\nthe month. The jobs publishes a message to a Pub/Sub topic containing secret\nID, Cloud SQL instance name, database, region and database user in the\npayload.\n\nThe message arrival on the pub/sub topic triggers a Cloud Run\nFunction , which uses the information provided in the message\nto connect to the CloudSQL instance via Serverless VPC\nConnector and changes the password. The function uses a\nservice account that has IAM roles required to\nconnect to the Cloud Sql instance.\n\nThe function then updates the secret in Secret Manager.\n\nNote : The architecture doesn't show the flow to restart the application\nafter the password rotation as shown in thee Generic architecture\nbut it can be added easily with minimal changes to the Terraform code.\n\nDeploy the architecture ¶\n\nThe code to build the architecture has been provided with this repository.\nFollow these instructions to create the architecture and use it:\n\nOpen Cloud Shell on Google Cloud Console and log in with your\ncredentials.\n\nIf you want to use an existing project, get role/project.owner role on the\nproject and set the environment in Cloud Shell as shown below. Then, move to\nstep 4.\n\n#set shell environment variable\nexport PROJECT_ID = \u003cPROJECT_ID\u003e\n\nReplace \u003cPROJECT_ID\u003e with the ID of the existing project.\n\nIf you want to create a new GCP project run the following commands in Cloud\nShell.\n\n#set shell environment variable\nexport PROJECT_ID = \u003cPROJECT_ID\u003e\n#create project\ngcloud projects create ${ PROJECT_ID } --folder = \u003cFOLDER_ID\u003e\n#associate the project with billing account\ngcloud billing projects link ${ PROJECT_ID } --billing-account = \u003cBILLING_ACCOUNT_ID\u003e\n\nReplace \u003cPROJECT_ID\u003e with the ID of the new project. Replace\n\u003cBILLING_ACCOUNT_ID\u003e with the billing account ID that the project should\nbe associated with.\n\nSet the project ID in Cloud Shell and enable APIs in the project:\n\ngcloud config set project ${ PROJECT_ID }\ngcloud services enable \\\ncloudresourcemanager.googleapis.com \\\nserviceusage.googleapis.com \\\n--project ${ PROJECT_ID }\n\nDownload the Git repository containing the code to build the example\narchitecture:\n\ncd ~\ngit clone https://github.com/GoogleCloudPlatform/platform-engineering\ncd platform-engineering/reference-architectures/automated-password-rotation/terraform\n\nterraform init\nterraform plan -var \"project_id= $PROJECT_ID \"\nterraform apply -var \"project_id= $PROJECT_ID \" --auto-approve\n\nNote: It takes around 30 mins for the entire architecture to get\ndeployed.\n\nReview the deployed architecture ¶\n\nOnce the Terraform apply has successfully finished, the example architecture\nwill be deployed in the your Google Cloud project. Before exercising the\nrotation process, review and verify the deployment in the Google Cloud Console.\n\nReview Cloud SQL database ¶\n\nIn the Cloud Console, using the naviagion menu select Databases \u003e SQL .\nConfirm that cloudsql-for-pg is present in the instance list.\n\nClick on cloudsql-for-pg , to open the instance details page.\n\nIn the left hand menu select Users . Confirm you see a user with the name\nuser1 .\n\nIn the left hand menu select Databases . Confirm you see see a database\nnamed test .\n\nIn the left hand menu select Overview .\n\nIn the Connect to this instance section, note that only\nPrivate IP address is present and no public IP address. This restricts\naccess to the instance over public network.\n\nReview Secret Manager ¶\n\nIn the Cloud Console, using the naviagion menu select\nSecurity \u003e Secret Manager . Confirm that cloudsql-pswd is present in the\nlist.\n\nClick on cloudsql-pswd .\n\nClick three dots icon and select View secret value to view the password\nfor Cloud SQL database.\n\nCopy the secret value, you will use this in the next section to confirm\naccess to the Cloud SQL instance.\n\nReview Cloud Scheduler job ¶\n\nIn the Cloud Console, using the naviagion menu select\nIntegration Services \u003e Cloud Scheduler . Confirm that\npassword-rotator-job is present in the Scheduler Jobs list.\n\nClick on password-rotator-job , confirm it is configured to run on 1st of\nevery month.\n\nClick Continue to see execution configuration. Confirm the following\nsettings:\n\nTarget type is Pub/Sub\n\nSelect a Cloud Pub/Sub topic is set to pswd-rotation-topic\n\nMessage body contains a JSON object with the details of the Cloud SQL\nisntance and secret to be rotated.\n\nClick Cancel , to exit the Cloud Scheduler job details.\n\nReview Pub/Sub topic configuration ¶\n\nIn the Cloud Console, using the naviagion menu select Analytics \u003e Pub/Sub .\n\nIn the left hand menu select Topic . Confirm that pswd-rotation-topic is\npresent in the topics list.\n\nClick on pswd-rotation-topic .\n\nIn the Subscriptions tab, click on Subscription ID for the rotator Cloud\nFunction.\n\nClick on the Details tab. Confirm, the Audience tag shows the rotator\nCloud Function.\n\nIn the left hand menu select Topic .\n\nClick on pswd-rotation-topic .\n\nClick on the Details tab.\n\nClick on the schema in the Schema name field.\n\nIn the Details , confirm that the schema contains these keys: secretid ,\ninstance_name , db_user , db_name and db_location . These keys will be\nused to identify what database and user password is to be rotated.\n\nReview Cloud Run Function ¶\n\nIn the Cloud Console, using the naviagion menu select\nServerless \u003e Cloud Run Functions . Confirm that pswd_rotator_function is\npresent in the list.\n\nClick on pswd_rotator_function .\n\nClick on the Trigger tab. Confirm that the field Receive events from has\nthe Pub/Sub topic pswd-rotation-topic . This indicates that the function\nwill run when a message arrives to that topic.\n\nClick on the Details tab. Confirm that under Network Settings VPC\nconnector is set to connector-for-sql . This allows the function to connect\nto the CloudSQL over private IPs.\n\nClick on the Source tab to see the python code that the function executes.\n\nNote: For the purpose of this tutorial, the secret is accessible to the\nhuman users and not encrypted. See\nthe section and Secret Manager best\npractice\n\nVerify that you are able to connect to the Cloud SQL instance ¶\n\nIn the Cloud Console, using the naviagion menu select Databases \u003e SQL\n\nClick on cloudsql-for-pg\n\nIn the left hand menu select Cloud SQL Studio .\n\nIn Database dropdown, choose test .\n\nIn User dropdown, choose user1 .\n\nIn Password textbox paste the password copied from the cloudsql-pswd\nsecret.\n\nClick Authenticate . Confirm you were able to log in to the database.\n\nRotate the Cloud SQL password ¶\n\nTypically, the Cloud Scheduler will automatically run on 1st day of every month\ntriggering password rotation. However, for this tutorial you will run the Cloud\nScheduler job manually, which causes the Cloud Run Function to generate a new\npassword, update it in Cloud SQL and store it in Secret Manager.\n\nIn the Cloud Console, using the naviagion menu select\nIntegration Services \u003e Cloud Scheduler .\n\nFor the scheduler job password-rotator-job . Click the three dots icon and\nselect Force run .\n\nVerify that the Status of last execution shows Success .\n\nIn the Cloud Console, using the naviagion menu select\nServerless \u003e Cloud Run Functions .\n\nClick function named pswd_rotator_function .\n\nSelect the Logs tab.\n\nReview the logs and verify the function has run and completed without\nerrors. Successful completion will be noted with log entries containing\nSecret cloudsql-pswd changed in Secret Manager! ,\nDB password changed successfully! and\nDB password verified successfully! .\n\nTest the new password ¶\n\nIn the Cloud Console, using the naviagion menu select\nSecurity \u003e Secret Manager . Confirm that cloudsql-pswd is present in the\nlist.\n\nClick on cloudsql-pswd . Note you should now see a new version, version 2\nof the secret.\n\nClick three dots icon and select View secret value to view the password\nfor Cloud SQL database.\n\nCopy the secret value.\n\nIn the Cloud Console, using the naviagion menu select Databases \u003e SQL\n\nClick on cloudsql-for-pg\n\nIn the left hand menu select Cloud SQL Studio .\n\nIn Database dropdown, choose test .\n\nIn User dropdown, choose user1 .\n\nIn Password textbox paste the password copied from the cloudsql-pswd\nsecret.\n\nClick Authenticate . Confirm you were able to log in to the database.\n\nDestroy the architecture ¶\n\ncd platform-engineering/reference-architectures/automated-password-rotation/terraform\n\nterraform init\nterraform plan -var \"project_id= $PROJECT_ID \"\nterraform destroy -var \"project_id= $PROJECT_ID \" --auto-approve\n\nConclusion ¶\n\nIn this tutorial, you saw a way to automate password rotation on Google Cloud.\nFirst, you saw a generic reference architecture that can be used to automate\npassword rotation in any password management system. In the later section, you\nsaw an example deployment that uses Google Cloud services to rotate password of\nCloud Sql database in Google Cloud Secret Manager.\n\nImplementing an automatic flow to rotate passwords takes away manual overhead\nand provide seamless way to tighten your password security. It is recommended to\ncreate an automation flow that runs on a regular schedule but can also be easily\ntriggered manually when needed. There can be many variations of this\narchitecture that can be adopted. For example, you can directly trigger a Cloud\nRun Function from a Google Cloud Scheduler job without sending a message to\npub/sub if you don't want to broadcast the password rotation. You should\nidentify a flow that fits your organization requirements and modify the\nreference architecture to implement it.\n\nBack to top",
|
|
"content_type": "text/html",
|
|
"query": "How is targeted rotation of Credentials/Keys performed in GCP Cloud Storage with automated or manual processes?",
|
|
"language": "en-US",
|
|
"round": 2,
|
|
"fetched": true,
|
|
"relevant": true,
|
|
"relevance": 0.76,
|
|
"source_quality": "primary",
|
|
"source_quality_score": 0.8240000000000001,
|
|
"actionable": true,
|
|
"covered_gap_ids": [
|
|
"GAP-003"
|
|
],
|
|
"assessment_reason": "Wiederverwendete semantisch äquivalente Recherche: Die Quelle beschreibt allgemein die Konzepte der automatisierten Passwortrotation in GCP, einschließlich der Verwendung von Secret Manager und Cloud Run, aber sie konzentriert sich nicht direkt auf Cloud Storage. Sie behandelt jedoch die allgemeine Architektur und Prozesse, die auf Cloud Storage anwendbar sind. Die Relevanz ist vorhanden, aber die konkreten Schritte für Cloud Storage fehlen."
|
|
}
|
|
}
|