Exportable crypto keys mean that an attacker can save exploit compromised software to extract it's private keys. This has been particularly high impact in some incidents, such as Solarwinds, where the SAML private key was exported (named a "Golden SAML" attack), allowing the attacker to sign SAML requests offline without producing audit trails and move laterally SAML-federated websites.
We should investigate using non-exportable cryptography (such as HSMs or KMS) for storing and accessing key material. Additionally, keys should be generated inside the HSM/KMS and not generated externally and imported.
The highest priority due to its very high impact is probably SSO. Keycloak however does not currently support this. This should be a consideration for any alternative SSO solutions we consider. Additionally, metadata should be sent to KMS, this attaches the login event's metadata to the audit data.
See
Additional key material to consider would be TLS keys, SSH keys, internal Kubernetes CAs, Istio CAs, and GitLab JWT secrets. These are all probably lower priority than SSO?
A side effect of doing this is you can also meet FIPS compliance too. All crypto operations are done in the HSM/KMS, so FIPS should not apply very much to the actual software any longer.
I am aware that this is quite difficult to implement generically across multi-cloud and on-prem. I think there's some differences between the different clouds' KMS APIs. HSM is an option for on-prem but costs $$$$. Using a TPM is also an option, but historically they are quite slow and not appropriate for real-time/online usage (I think fTPM are faster now though?).
Exportable crypto keys mean that an attacker can save exploit compromised software to extract it's private keys. This has been particularly high impact in some incidents, such as Solarwinds, where the SAML private key was exported (named a "Golden SAML" attack), allowing the attacker to sign SAML requests offline without producing audit trails and move laterally SAML-federated websites.
We should investigate using non-exportable cryptography (such as HSMs or KMS) for storing and accessing key material. Additionally, keys should be generated inside the HSM/KMS and not generated externally and imported.
The highest priority due to its very high impact is probably SSO. Keycloak however does not currently support this. This should be a consideration for any alternative SSO solutions we consider. Additionally, metadata should be sent to KMS, this attaches the login event's metadata to the audit data. See
Additional key material to consider would be TLS keys, SSH keys, internal Kubernetes CAs, Istio CAs, and GitLab JWT secrets. These are all probably lower priority than SSO?
A side effect of doing this is you can also meet FIPS compliance too. All crypto operations are done in the HSM/KMS, so FIPS should not apply very much to the actual software any longer.
I am aware that this is quite difficult to implement generically across multi-cloud and on-prem. I think there's some differences between the different clouds' KMS APIs. HSM is an option for on-prem but costs $$$$. Using a TPM is also an option, but historically they are quite slow and not appropriate for real-time/online usage (I think fTPM are faster now though?).