has anyone replaced github secret use in GHA with gcp secret manager and were there any specific mitigations you put in place to keep the secrets from GCP secret manager secure once read in to a github action workflow (between jobs/etc.?)? or with the identity itself-- one thing there is I’m trying to force a different identity for PR branches vs master and then treating PR identities as the dev-level secret vs prod level secrets for master
We exclusively use a workload identity pool for GitHub which is managed using Terraform. Every repo has its own SA for GHA and sometimes we even throw in different SAs per GitHub environment. No secrets are stored and none are referenced in any workflows. We also have locked down our reusable workflows so that only trusted people may edit these and we never give out permissions that lets users edit repo and env variables
so your workflows don’t consume any secrets? or the actual compute they’re running on does so direct within the code itself, vs from the github action and passing it along?
Yep, uses WLI, check out: https://github.com/terraform-google-modules/terraform-google-github-actions-runners/tree/main/modules/gh-oidc
I do all of that already securely with workload identities — the question is how do you actually retrieve and use secrets within a github action in a secure fashion and if you’re doing anything special there within the actions themselves? if you just use them in an action they aren’t passed around securely from what we’ve seen
that module itself works – but I don’t use it – it was built as a POC but not really with security in mind
Exactly right, ! No secrets are exposed in or consumed by workflows. Everything is stored in secret manager and directly referenced through the service using Terraform via service accounts and IAM. The applications hosted on the service will then have access to the exposed secrets
We have also further shut down the ability to view these secrets using just in time (JIT) access, only available for a handful of trusted platform people
one thing I’m trying to get to is splitting off identity for PR vs master branch and not sharing the same – and treating the PR identity as a dev-level environment with actual different secrets if needed
This is exactly what we do for our main frontend application. We essentially have two SAs that are only allowed to deploy to each Cloud Run service (we migrated recently from Kubernetes to Cloud Run). One for PRs (preview) and one for push events to main (prod). With the help of custom scripts, safeguards and github environments, one can’t mess with the workflows in order to potentially fuck up the deployments
Sorry, WLI = work load identify
