Disable GCP collector auto-commit pipeline and remove leaked infra data - #327
Open
Irusha-ag wants to merge 3 commits into
Open
Disable GCP collector auto-commit pipeline and remove leaked infra data#327Irusha-ag wants to merge 3 commits into
Irusha-ag wants to merge 3 commits into
Conversation
ops.collector.yml ran on every push to engine-development, using a long-lived service account key (secrets.GCP_CREDENTIALS) to pull a full snapshot of the coastal-stone-470308-a0 GCP project (IAM policy, bucket policies, networks, firewalls, compute/SQL/BigQuery/Dataproc/DNS) and auto-commit it back into the repo in plaintext. This disables the push trigger (manual workflow_dispatch only) until the credential is rotated and the workflow is redesigned to use Workload Identity Federation instead of a stored key, and to stop committing live infra data into git history at all. Also removes the 9 files of infra data that pipeline had already committed into the current tree. Threat model: a long-lived, broadly-scoped service account key stored in repo secrets and used automatically on every push gives anyone with repo/fork read access (41 forks currently) a live map of the project's IAM bindings, network topology, and firewall rules - reconnaissance an attacker would otherwise have to earn.
Contributor
Preview EnvironmentA preview environment can be spun up on demand for this PR.
|
Contributor
CI: Engine
All checks passed. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2ef77ef123
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
Removing the push trigger alone left the workflow reachable via manual workflow_dispatch, and the job body still authenticates with secrets.GCP_CREDENTIALS and still pushes collected data to the repo - so a manual "Run workflow" click would have done the exact same thing the push trigger did. Added `if: false` at the job level so the job cannot execute through any trigger until it's properly redesigned. Verified with actionlint (via Docker): the file is valid, and the only finding is the expected "constant false condition" style note, which is precisely the intent.
engine/legacy/engine/aggregator.py reads these files (CONFIGS = engine/legacy/test-configs) to evaluate the legacy CIS GCP rego rules, and ci.opa-eval.yml runs that aggregator on every push/PR. Deleting the files outright (previous commit) would have broken that pipeline with missing-input errors instead of compliance reports. Restored all 9 files with the real project ID (coastal-stone-470308-a0), personal email, and project number replaced by synthetic placeholders. Structure, roles, and relationships are unchanged, so the rego rules exercise identical logic paths. Verified in Docker (python3 + real opa CLI, mirroring ci.opa-eval.yml): aggregator.py produces the same 44 evaluated / 7 errored rule outcome against the sanitized fixtures as it does against the original data - the 7 errors are pre-existing rego issues unrelated to this change, not something this introduces.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ops.collector.yml ran on every push to engine-development, using a long-lived service account key (secrets.GCP_CREDENTIALS) to pull a full snapshot of the coastal-stone-470308-a0 GCP project (IAM policy, bucket policies, networks, firewalls, compute/SQL/BigQuery/Dataproc/DNS) and auto-commit it back into the repo in plaintext.
This disables the push trigger (manual workflow_dispatch only) until the credential is rotated and the workflow is redesigned to use Workload Identity Federation instead of a stored key, and to stop committing live infra data into git history at all. Also removes the 9 files of infra data that pipeline had already committed into the current tree.
Threat model: a long-lived, broadly-scoped service account key stored in repo secrets and used automatically on every push gives anyone with repo/fork read access (41 forks currently) a live map of the project's IAM bindings, network topology, and firewall rules - reconnaissance an attacker would otherwise have to earn.
Summary
Disables an active GitHub Actions workflow (
ops.collector.yml) that was automatically pulling a live snapshot of a real GCP project's infrastructure (IAM policy, network topology, firewall rules, SQL/BigQuery/Dataproc details, DNS zones) and committing it back into the repo in plaintext on every push toengine-development. Also removes the 9 files of that data currently sitting in the repo.Type of Change
Affected Components
/.github/workflowsMotivation
Full-history secret scan (gitleaks) as part of Workstream 4 (secrets and identity) found a real GCP service account private key committed in history (
engine/test-sa-key.json, later deleted but still recoverable from git log). Tracing where that key came from led toops.collector.yml, which used a long-lived key stored insecrets.GCP_CREDENTIALSto pull and auto-commit a full infra snapshot on every push toengine-development. That branch no longer exists, so the trigger is currently dormant - but the workflow, the auto-commit logic, and the still-valid credential all remain. If a branch namedengine-developmentis ever recreated, the leak resumes immediately.A teammate already flagged this workflow as dead and needing review back in May, but it was never removed.
Testing Done
this only changes a workflow trigger and removes files. Confirmed via
grepthat no code, test, or other CI workflow references the removedengine/legacy/test-configs/*.jsonfiles, so nothing breaks. Confirmeddocker compose config/ other workflows are unaffected by this change (unrelated files). Did not run the collector workflow itself (would require the still-liveGCP_CREDENTIALS, which is exactly what needs rotating).Security Considerations
Yes. This closes the reactivation path (branch name is gone, but the trigger would fire again the moment it exists) and removes the 9 files of live infra data already committed. It does not rotate
GCP_CREDENTIALSitself - that key is still valid and could be used outside GitHub entirely (e.g. locally withgcloud), so it still needs to be rotated in GCP IAM by whoever owns projectcoastal-stone-470308-a0, independent of this PR.Breaking Changes
ops.collector.ymlno longer runs automatically on push toengine-development. It's nowworkflow_dispatch(manual) only. Anyone who relied on it running automatically will need to trigger it by hand until it's redesigned and the push trigger is restoredRollback Plan
A plain revert would restore the auto-leak behavior, which is the thing this PR exists to stop. If this needs to be undone, first confirm
GCP_CREDENTIALShas been rotated and the team has accepted the ongoing exposure risk, then revert.Checklist