Credentials an integration needs — an SSH key for a file transfer, a certificate for a signed call, a password for a legacy endpoint — usually land wherever the person configuring the integration could put them. This release makes the platform's keystore the place they live, and makes who may touch them an explicit, audited decision.
SSH key pairs, generated or imported
- Three algorithms. Key pairs are generated or imported for RSA, ECDSA and Ed25519, and exported when the far side needs the public half.
- OpenSSH container format. The cryptography layer reads the OpenSSH private-key container for all three algorithm families, so a key produced by the standard tooling is imported as it is.
- Pasted as well as uploaded. Key-pair and certificate content is pasted directly as an alternative to uploading a file, which is what an operator working from a terminal actually has to hand.
- Password secrets alongside. A keystore entry carries password secrets, so the credential that is not a key or a certificate has the same home and the same controls.
Who may act, and what was done
- Owners and managers only. Destructive and administrative actions are restricted to the entry's owner and its managers, so deleting or re-issuing a credential is not available to everyone who can read the list.
- Per-keystore manager roles. Management rights are granted per keystore rather than globally, so delegating one credential store does not delegate them all.
- Secrets in the audit log. Adding and deleting a secret are recorded as their own audited actions, and the audit-log grids gain filters so a specific change is found rather than scrolled to.
Existing keystore entries and their certificates are unaffected; the ownership rules apply to the administrative actions, leaving read access governed as it was.