Half your configs live in Git. The other half hide behind Google permissions that expire right when production deploys are due. If this feels too familiar, you are not alone. Getting Drone and Google Cloud Deployment Manager to play nicely together still trips up good engineers every week.
Drone outfits your pipeline with automated builds and deploys that react instantly to Git changes. Google Cloud Deployment Manager does the heavy lifting of creating infrastructure from declarative templates. Used together, you can push code and watch infrastructure shift without human interference. When wired correctly, it is reliable enough to run in regulated or SOC 2 environments.
Here is the real trick. The integration depends on identity, not scripts. Each Drone pipeline run needs a consistent way to authenticate with Google Cloud and prove it can deploy infrastructure. Instead of handing out static service keys, teams are moving toward short-lived tokens bound to an identity provider like Okta or Google Workspace. That means one security policy governs both build and deploy stages.
To connect Drone with Google Cloud Deployment Manager, map Drone’s runner credentials to a service account that can trigger Deployment Manager templates. Grant minimal IAM roles—typically deploymentmanager.editor—and limit token lifetime. Use OIDC tokens if you can. The build process then requests an ephemeral credential and executes Deployment Manager templates directly in your target project.
A common mistake is relying on long-lived secrets embedded in Drone’s configuration. Those age poorly and introduce silent access creep. Rotate them or eliminate them entirely. Platforms like hoop.dev turn those access rules into guardrails that enforce policy automatically. Tokens refresh, permissions shrink, and no one has to babysit YAML anymore.