Three ordinary writes replaced or removed account Secrets. A duplicate
create seeded before learning the release existed, so it replaced the
live application's Secrets and then removed its own. Server dry-run
wrote and pruned for real, and a dry-run mint replaced the password.
An update seeded every declared account without a Secret, which after
the conversion swaps a working password for a discarded one.
A create now stops on an existing release before touching a Secret,
and replaces any leftover at an account's name unless a live release
owns it, so the new account always gets a fresh identity and an owner.
Dry-run writes nothing anywhere. An update seeds only the accounts it
adds. A mint requires a declared account even where the Secret
exists, and the write paths read through the uncached client, since a
stale read here is a replaced or recreated Secret.
Assisted-by: LLM
Signed-off-by: Timofei Larkin <lllamnyp@gmail.com>
Comments carry the mechanism, not the rationale; every argument removed
here is in the design proposal or the PR. Where one claim appeared at
several sites, the copy at the site that constrains the code stays.
Assisted-by: LLM
Signed-off-by: Timofei Larkin <lllamnyp@gmail.com>
CodeQL flags the SHA-1 and SHA-256 of a password as weak hashing of
sensitive data. Both are the forms the engines store and check against
and accept in no other form, and the design relies on the 32-character
random password rather than on the digest for strength, so the alerts
are dismissed with that reason and the code says it where the hashing
happens.
Assisted-by: LLM
Signed-off-by: Timofei Larkin <lllamnyp@gmail.com>
The Credential view lists the account Secrets of the namespace by label
and skips any no live HelmRelease owns, so no kind is served until its
definition carries a credentials block. A mint replaces the stored value
in one conditional write keyed on the Secret's resourceVersion and
returns the plaintext once; a revoke discards it. Both record an Event
on the application, which needs create on events.
The application registry seeds an account Secret per declared account
before it writes the HelmRelease, so the chart can reference them from
the first render, prunes the Secrets of removed accounts after the
write, and refuses to delete an application whose release is suspended,
since Flux skips the uninstall and would leave the database running
with the Secrets gone. The ApplicationDefinition reconciler computes
the per-account valuesFrom entries with the function the API uses, so a
release that predates the block gets them on its next reconcile. Schema
defaulting moves to a package both can import.
A definition declaring a format or an account source that is not built
leaves its kind unserved rather than served with passwords the API
cannot issue. Tenant roles gain get and list on credentials at view and
create on mint and revoke at admin and for the tenant ServiceAccount.
Attribution comes from the kube-apiserver audit log, so the operations
docs get a policy for distributions that ship none, and
monitoring-agents a value for an extra fluent-bit output so a SIEM can
receive the log without dropping the VictoriaLogs outputs.
Assisted-by: LLM
Signed-off-by: Timofei Larkin <lllamnyp@gmail.com>
Cozystack generates managed application passwords at Helm render time
and keeps them in a Secret tenants can read again at any time, which a
deployment whose policy requires a credential shown once cannot accept.
The accepted design moves generation into the API: an
ApplicationDefinition declares its accounts and the stored form of a
password in a credentials block, and each account gets a
core.cozystack.io Credential whose mint and revoke subresources take a
TokenRequest-shaped CredentialRequest.
This adds the types, the built-in password formats, which the migration
CLI shares so a converted release and a mint store the same form, and
the account helpers that name the Secrets and read their record.
Design: https://github.com/cozystack/community/blob/main/design-proposals/user-secrets-api/README.md
Assisted-by: LLM
Signed-off-by: Timofei Larkin <lllamnyp@gmail.com>
Timofei Larkin