Keeping secrets out of deployment files: checks & response

Keep credential values out of deployment files: put a reference to the secret there, then have the workload retrieve the value through a controlled method. Check source files and the delivery path, including build output and logs.

If a real credential is committed, treat it as compromised and revoke or rotate it immediately. Deleting the value alone does not stop its use.

Separate the reference from the value

List each deployment credential, its owner, the service it reaches, the workloads that use it and its replacement method. This identifies which workload needs access and what must change if a credential leaks.

A Red Hat build of Keycloak custom resource shows a concrete reference: under additionalOptions, set secret with name: http-client-secret and key: poolSize. The file names the Secret and key rather than containing the secret value.

First check whether workload identity and temporary credentials can serve the connection. On Compute Engine and Cloud Run functions, Google Cloud client libraries obtain credentials through the instance metadata server; on GKE, Workload Identity provides credentials through a metadata service.

For workloads on Amazon Web Services or Microsoft Azure that need Google Cloud APIs, Google recommends workload identity federation using existing identity mechanisms. For local development, gcloud auth application-default login creates credentials that client libraries can pick up.

If a secret is necessary, store it in Google Cloud Secret Manager and use the Secret Manager API directly where practical. Google warns that file and environment-variable delivery can expose secrets through file access or application behaviour.

Have the workload retrieve the secret using its identity, and grant only the minimum necessary Secret Manager permissions. Use a curated role or a custom role where needed.

Separate staging and production into different Google Cloud projects to isolate environments with project-level IAM. For secrets shared in one project, use secret-level IAM bindings or IAM Conditions to limit access; IAM Recommender can help identify over-privileged bindings.

Review who can read a secret and who can change the workload identity or reference. Someone able to alter those controls may gain access through another route.

Check leak paths

Review source files, manifests, infrastructure templates, sample configuration, pipeline variables, build artefacts and diagnostic logs. Use examples that cannot authenticate, and keep development and production credentials separate.

GitHub repository push protection blocks detected secrets before they reach protected repositories, but it requires GitHub Secret Protection and is disabled by default. A repository administrator, organisation owner, security manager or enterprise owner can enable it at repository, organisation or enterprise level.

Repository push protection covers command-line pushes, commits made in the GitHub UI, file uploads and REST API requests; GitHub MCP server interactions are covered for public repositories. Bypasses are possible, so review bypass alerts and do not treat a clean scan as proof that no secret is present.

GitHub user-level push protection is enabled by default on GitHub.com for pushes to public repositories. It does not generate bypass alerts unless repository-level push protection is also enabled.

Organisations on GitHub Team and GitHub Enterprise can run a free report to scan their code for leaked secrets. The report also shows how many leaks push protection could have prevented.

Review new credential paths and unusual generated or encoded values alongside scanning. A scanner catches supported patterns, not every possible credential.

GitHub secret protection metrics

Respond to a committed credential

Treat a leaked credential as immediately compromised. Identify its type and provider, the repository, file and line, and the owner; use the repository's CODEOWNERS file to find the responsible team and git log -S to help locate the commit.

If GitHub secret scanning provides an alert, check its validity status where available. Validity checks cover only certain secret types, and the provider is the most reliable source for determining whether a credential is still active.

Revoke or rotate the credential with its provider before considering history cleanup. Removing it in a new commit, or deleting and recreating the repository, does not stop the old credential from being used.

Provide a replacement to affected applications and confirm the workload can use it. Review available evidence of unauthorised use, then record the old credential's retirement and the new deployment reference.

Rewriting repository history with a tool such as git-filter-repo may be useful after revocation or rotation, but requires careful coordination with collaborators. Old clones can reintroduce the secret, and rewriting changes commit hashes and can disrupt repository work.