coilyco-flight-deck/infrastructure

Watch

Two unignored AWS credential files sit at the root of the infrastructure checkout #899

New issue

Open

opened 2026-08-22 21:17:53 +00:00 by coilyco-ops · 1 comment

coilyco-ops commented

2026-08-22 21:17:53 +00:00

Member

Filed by Darren (director, claude seat) while checking whether #1004 in agentic-os still reproduces. Not caused by that work, found beside it.

What is on disk

The canonical infrastructure checkout at $PROJECTS_ROOT/coilyco-flight-deck/infrastructure holds two files at its root:

?? aws-access-key-id        21 bytes
?? aws-secret-access-key    41 bytes

?? is untracked, and git check-ignore -v exits 1 for both, so they are untracked and unignored. The sizes match a 20-character AWS access key ID and a 40-character secret, each with a trailing newline. I did not read either file, and their contents do not belong in an issue.

Why it is worth an issue rather than a quiet cleanup

Any git add -A or git add . in that checkout stages live credentials. trufflehog runs at commit time and is the backstop that would catch it, and the standing rule is that the discipline sits upstream of the hook. Right now nothing upstream of the hook is holding.

The exposure window is small and the blast radius is not. This is a repository whose whole job is infrastructure convergence.

What I did not do

I left both files exactly as found. They are Kai's local operational state in a checkout I do not own, they may be actively feeding a bootstrap path, and deleting an operator's credentials to fix a gitignore gap trades one problem for a worse one.

Suggested

Add both names to .gitignore, which is the part that is unambiguously safe and belongs in the repository regardless of where the files end up.
Then decide separately whether the checkout root is where they should live at all. bootstrap.sh sits beside them, so there may be a reason. If there is, the gitignore entry should carry it as a comment.
If they are stale, Kai removes them and rotates.

Ordering matters: the gitignore entry is the cheap half and closes the window on its own.

**Filed by Darren (director, claude seat)** while checking whether #1004 in agentic-os still reproduces. Not caused by that work, found beside it. ## What is on disk The canonical `infrastructure` checkout at `$PROJECTS_ROOT/coilyco-flight-deck/infrastructure` holds two files at its root: ``` ?? aws-access-key-id 21 bytes ?? aws-secret-access-key 41 bytes ``` `??` is untracked, and `git check-ignore -v` exits 1 for both, so **they are untracked and unignored**. The sizes match a 20-character AWS access key ID and a 40-character secret, each with a trailing newline. I did not read either file, and their contents do not belong in an issue. ## Why it is worth an issue rather than a quiet cleanup Any `git add -A` or `git add .` in that checkout stages live credentials. `trufflehog` runs at commit time and is the backstop that would catch it, and the standing rule is that the discipline sits upstream of the hook. Right now nothing upstream of the hook is holding. The exposure window is small and the blast radius is not. This is a repository whose whole job is infrastructure convergence. ## What I did not do I left both files exactly as found. They are Kai's local operational state in a checkout I do not own, they may be actively feeding a bootstrap path, and deleting an operator's credentials to fix a gitignore gap trades one problem for a worse one. ## Suggested * Add both names to `.gitignore`, which is the part that is unambiguously safe and belongs in the repository regardless of where the files end up. * Then decide separately whether the checkout root is where they should live at all. `bootstrap.sh` sits beside them, so there may be a reason. If there is, the gitignore entry should carry it as a comment. * If they are stale, Kai removes them and rotates. Ordering matters: the gitignore entry is the cheap half and closes the window on its own.

coilyco-ops added the

labels

2026-08-22 21:17:53 +00:00

coilyco-ops commented

2026-08-22 21:25:30 +00:00

Author

Member

Resolved on Kai's call: both files removed. Recording what I checked before deleting, since the delete was irreversible.

They were a redundant copy, not the only copy

The names match the basenames of the SSM parameter paths in scripts/provision-ward-mcp-ssm-key.sh:

/ward-mcp/ssm/aws-access-key-id
/ward-mcp/ssm/aws-secret-access-key

That script never writes files. It mints the ward-mcp-ssm key and puts both values straight into SSM as SecureString, then unsets the shell variables. So the root files were not its output. They look like a redirect landing in the checkout root, which also explains the names.

aws ssm describe-parameters confirms both parameters exist, SecureString, version 1, last modified 2026-07-22. Metadata only, no values read. The canonical copies are intact, so removing the local ones lost nothing.

Nothing in the repository reads either path. The only reference to those names is the SSM path constant in the provisioning script.

I did not read either file's contents at any point.

Still open on this issue

The .gitignore entry. Removing the files closes today's window and nothing stops the same redirect landing there again. The entry is still worth adding, and Kai chose removal rather than both, so I am leaving the entry to a deliberate decision rather than folding it in.
Rotation. The key is a static IAM workload credential that sat unencrypted in a working tree for an unknown period, on a machine that runs agents. Version 1 dated 2026-07-22 means it has not been rotated since it was minted. The provisioning script refuses to overwrite an existing key and says to rotate explicitly, so rotation is a deliberate ops action rather than a re-run of that script. Worth doing on the assumption the file was exposed, since nothing here can prove it was not.

Neither is mine to take. Both belong to a DevOps seat or to Kai.

**Resolved on Kai's call: both files removed.** Recording what I checked before deleting, since the delete was irreversible. ## They were a redundant copy, not the only copy The names match the **basenames** of the SSM parameter paths in `scripts/provision-ward-mcp-ssm-key.sh`: ``` /ward-mcp/ssm/aws-access-key-id /ward-mcp/ssm/aws-secret-access-key ``` That script never writes files. It mints the `ward-mcp-ssm` key and puts both values straight into SSM as `SecureString`, then unsets the shell variables. So the root files were not its output. They look like a redirect landing in the checkout root, which also explains the names. `aws ssm describe-parameters` confirms both parameters exist, `SecureString`, version 1, last modified 2026-07-22. Metadata only, no values read. The canonical copies are intact, so removing the local ones lost nothing. Nothing in the repository reads either path. The only reference to those names is the SSM path constant in the provisioning script. I did not read either file's contents at any point. ## Still open on this issue * **The `.gitignore` entry.** Removing the files closes today's window and nothing stops the same redirect landing there again. The entry is still worth adding, and Kai chose removal rather than both, so I am leaving the entry to a deliberate decision rather than folding it in. * **Rotation.** The key is a static IAM workload credential that sat unencrypted in a working tree for an unknown period, on a machine that runs agents. Version 1 dated 2026-07-22 means it has not been rotated since it was minted. The provisioning script refuses to overwrite an existing key and says to rotate explicitly, so rotation is a deliberate ops action rather than a re-run of that script. Worth doing on the assumption the file was exposed, since nothing here can prove it was not. Neither is mine to take. Both belong to a DevOps seat or to Kai.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

coilyco-flight-deck/infrastructure#899

No description provided.

Rows
Columns