No alert, and a status that sees what happened to the machine - #58
Merged
Merged
Conversation
**The email alert is gone.** It promised you would find out within a minute
when anyone else touched the machine, and measured against real audit entries
it caught almost none of what it named:
- a snapshot of the data disk is logged against the *disk* -- `gce_disk`,
`disk_id`, no instance id -- and the alert matched only the VM's id;
- the data disk attached to somebody else's VM is logged against *their* VM,
with ours only in `request.source`, which the alert did not read;
- `recreate` gives the VM a new instance id, and the alert was never
refreshed -- it skipped a policy that already existed -- so after one
rebuild it watched a machine that no longer existed;
- and the ssh logging the README once promised was never switched on.
What it did catch was a changed startup script or a reset. A promise to mail
you is worse than none when the mail does not come, and making it keep that
promise needs a second identity to test with and a permission change in the
project. It can come back when that is worth doing. `destroy` still removes the
policy a machine from before this carries, since nothing else would.
**`status` keeps the other half, and now answers it.** It had the same filter
and the same blind spots. It asks by *name* now -- the VM, the data disk, and
the data disk named inside somebody else's attach request -- which survives a
rebuild and finds the disk wherever it turns up, and it lists whatever anyone
else did rather than guessing at a list of verbs. A permission change on the
project is in it, because that is how somebody grants themselves ssh; Google's
own compute-system account is not, because it takes the scheduled snapshots and
nobody can act as it.
Measured on the audit entries of a throwaway disk and VM, snapshotted and then
attached: read as if by somebody else, all six events listed once each --
including the snapshot and the attach the old filter could not see -- and read
as the one who did them, none.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
andrin-n-dream
force-pushed
the
workmachine
branch
from
September 18, 2026 21:15
d497c38 to
67eee72
Compare
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
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.
The email alert is removed
It promised you'd find out within a minute when anyone else touched the machine.
Measured against real audit entries (a throwaway disk and VM, snapshotted and
then attached), it caught almost none of what it named:
gce_disk,disk_id, no instance id). The alert matched only the VM's instance id.ours appears only in
request.source, which the alert didn't read.recreatethe VM has a new instance id and the alert was neverrefreshed — it skipped a policy that already existed — so it watched a machine
that no longer existed.
What it caught was a changed startup script or a reset. A promise to mail you is
worse than none when the mail doesn't come, and making it keep that promise needs
a second identity to test with and a permission change in the project.
destroystill removes the policy that older machines carry.
statuskeeps the other half, and now answers itIt had the same filter and the same blind spots. It asks by name now — the
VM, the data disk, and the data disk inside someone else's attach request — which
survives a rebuild and finds the disk wherever it turns up, and it lists whatever
anyone else did rather than guessing a list of verbs. A permission change on the
project is included (that's how someone grants themselves ssh); Google's own
compute-system account, which takes the scheduled snapshots, is not.
Measured on the probe's audit entries: read as if by someone else, all six
events listed once each — including the snapshot and attach the old filter
couldn't see — and read as the one who did them, none.
🤖 Generated with Claude Code