When a machine is deleted with `clan machines delete`, remove its
vars and legacy secrets, and update any secrets that reference the
machine's key.
This command is a superset of `clan secrets machine delete`, and I am
wondering if we could remove the `clan secrets machine` subcommand,
unless there is an use case for having a machine defined without its
key, and any secrets/vars?
Note:
- This deletes the `ListSecretsOptions` dataclass, as it did not seem to
bring any value, especially since `list_secrets` was receiving its
individual members instead of the whole dataclass. We can always bring
it back if complexity grows to demand it.
Quick follow up to PR #2781, this commit does the same kind of logic but
for machines instead of users and groups.
Note that this only affects the `clan secrets machines remove`
sub-command, and that `clan machines delete` still leaves unusable
secrets & vars behind. This can be addressed in a different change.
We need to remove all keys that were in the group from affected secrets.
With this change we now take `group_name` as an argument in
`{add,remove}_member`, which is a little bit more readable than
`group_folder.parent.name`, and helps DRY the code a bit.
- Move public keys collection to a class method on `SopsKey`, and
implement collection for each key type in `KeyType`, this helps make
the code more generic ;
- Replace `Operation.__call__` by `run` (`sops.run` if you import the
entire module), that allows us to dedent the code so that's cool ;
- Fix exception handling when trying to get a in-memory temporary file ;
- Make Executor cuter 😵🪦.
vars changes in question are from commit: 54b8f5904e
With this changeset the age specific sops logic that was added is now
generic.
To keep things simple, this changeset modifies `SopsKey` so that
`username` is ignored when comparing different keys. I don't really see
us relying on `username` and this makes `SopsKey` hashable, and usable
in a `set`, which is nice when you check that you have a particular key.
This forces sops to use our config file, otherwise if any of the
environment variables set to specify recipients is present then
`--config` will be ignored (see [env_check]).
That's simple enough, still I ended up refactoring how we call sops for
correctness, and to align with its behavior. The code now distinguishes
between public and private keys explicitly. `secrets.decrypt_secret`
does not try to lookup for public and private keys anymore.
With this changeset, some people might have to adjust their environment
as public age and PGP keys will be discovered like sops would do. In
particular if multiple public keys are discovered, then the user will
have to specify which one to use for the clan.
This also makes the following changes:
- try to use `/dev/shm` when swapping a secret (it's what [pass] does
fwiw);
- alias immediate values for readability;
- remove some float comparison that could never succeed, and use sops'
exit status instead;
- remove unused function `maybe_get_sops_key`.
[env_check]: 8c567aa8a7/cmd/sops/main.go (L2229)
[pass]: http://passwordstore.org/
When the users of a secret change, when for example a new admin user is added, an error will be thrown when generating vars, prompting the user to pass --fix to re-encrypt the secrets
I am not sure to understand what `extract_public_key` was for. It seems
like `age-keygen -y` will just work fine for a file like
`extract_public_key` is looking for. Unless someone intentionally made a
file with a comment like that without the private key in it.
Messages are moved to stdout rather being logged. It feels like the
output is meaningful in the first step users are going to take. Also
makes testing easier, as log messages are captured differently than
stdout. The call to add an user is changed to be easier to copy paste
and work whether PGP or age is in use.
A description for the command is added instead of help which does not
seem to be displayed.
To use a PGP key instead of an age key you can set `SOPS_PGP_FP`. (You
can use `gpg -k --fingerprint --fingerprint` to get your PGP encryption
key fingerprint, remove spaces from it).
The internal manifest file already supported a type field, and so I built
from there.
With those changes, I was able to add my PGP key, and update all my
secrets with it, instead of the age key originally generated:
```
% clan secrets key show | jq
{
"key": "ADB6276965590A096004F6D1E114CBAE8FA29165",
"type": "pgp"
}
% clan secrets key update
% for s in $(clan secrets list) ; do clan secrets users add-secret kal-pgp-from-2022-12-to-2024-12 "$s"; done
% for s in $(clan secrets list) ; do clan secrets users remove-secret --debug kal "$s" ; done
```
