Hi all, we are getting together fields that can obtain their value from the vault. We decided to start with a small subset of fields and then add more if needed. Suggested subset is following: - SMTP password - LDAP password - Identity provider secret

Thank you for responding Stian. Comments below. On Thu, Aug 22, 2019 at 1:58 PM Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: > - Client secret (should be easy) >> > > -1 We should recommend jwt auth or mtls here instead as it provides better > security. When those are used Keycloak only stores the public part so > doesn't need to be stored securely. > > Well, you are right. Why do we have secrets then? Can it be removed and replaced by jwt or mtls? > >> There are also other fields which we were considering, however, we decided >> not to add them for now. Feel free to comment on any of these fields or >> suggest new once. We are open to add any new fields in case of reasonable >> arguments. >> >> - KeyProviders - This part should be probably added soon as some >> follow-up >> work. It might be a little bit tricky as we don't want to duplicate each >> KeyProvider with its Vaul*KeyProvider version. >> > > Can't we just add an option to existing providers to be able to load keys > from the vault? > I am sure there is a possibility of how to do it in an elegant way. I haven't investigated it yet (maybe some else have). The question at the moment is, whether to include it in the initial implementation or do it as follow-up work.

> > - Credential Attributes >> > > What credential attributes? Can you give some examples here? > I was not sure what exactly is stored in there, so I rather put it here to obtain feedback if somebody knows about something which is worth storing in the vault. > > - Federated User Credentials >> > > These are just stored as hashed passwords right? As user credentials they > should be encrypted in db not stored in the vault. > It should be the same as User Credentials

_______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

Sorry, but I'm not quite following the vault idea in Keycloak. If I understood the requirements correctly and based on the motivation from the design document, the main idea is that "A number of credentials are currently stored in plaintext in the Keycloak database. This is less than ideal as it can be costly and hard to provide the sufficient layer of protection at the database level." It seems to me that we should first try to encrypt sensitive data in the database (we need that anyways don't we?) where the vault would be more like a usability improvement (also a security improvement since you have secrets from a single place) so that people can avoid duplicating sensitive data across different services deployed in the cloud. Taking k8s as an example and the file-based vault that was implemented, it will help to centralize credentials so that they are provided by k8s instead of setting it directly in Keycloak. My point is that if we can securely store data we are also addressing the confidentiality problem. As Stian said, some credentials/secrets don't make sense in the vault. For those that make sense, vault would be useful to centralize how they are managed/fetched (using k8s secrets, hashcorp, etc). Where the vault would be a great improvement to overall security too, so that admins don't need to spread credentials across different services, thus making easier to change secrets accordingly when confidentiality is compromised. On Fri, Aug 23, 2019 at 8:33 AM Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: > On Fri, 23 Aug 2019 at 12:11, Michal Hajas <mhajas(a)redhat.com&gt; wrote: > > > Thank you for responding Stian. Comments below. > > > > On Thu, Aug 22, 2019 at 1:58 PM Stian Thorgersen <sthorger(a)redhat.com&gt; > > wrote: > > > > > - Client secret (should be easy) > > >> > > > > > > -1 We should recommend jwt auth or mtls here instead as it provides > > better > > > security. When those are used Keycloak only stores the public part so > > > doesn't need to be stored securely. > > > > > > Well, you are right. Why do we have secrets then? Can it be removed > and > > replaced by jwt or mtls? > > > > > > > >> There are also other fields which we were considering, however, we > > decided > > >> not to add them for now. Feel free to comment on any of these fields > or > > >> suggest new once. We are open to add any new fields in case of > > reasonable > > >> arguments. > > >> > > >> - KeyProviders - This part should be probably added soon as some > > >> follow-up > > >> work. It might be a little bit tricky as we don't want to duplicate > each > > >> KeyProvider with its Vaul*KeyProvider version. > > >> > > > > > > Can't we just add an option to existing providers to be able to load > keys > > > from the vault? > > > > > > > I am sure there is a possibility of how to do it in an elegant way. I > > haven't investigated it yet (maybe some else have). The question at the > > moment is, whether to include it in the initial implementation or do it > as > > follow-up work. > > > > Follow-up > > > > > > > > > > - Credential Attributes > > >> > > > > > > What credential attributes? Can you give some examples here? > > > > > > > I was not sure what exactly is stored in there, so I rather put it here > to > > obtain feedback if somebody knows about something which is worth > storing in > > the vault. > > > > > > > > - Federated User Credentials > > >> > > > > > > These are just stored as hashed passwords right? As user credentials > they > > > should be encrypted in db not stored in the vault. > > > > > > > It should be the same as User Credentials > > > > As a general note credentials/secrets for users and clients should not be > stored in the vault, and should rather be encrypted at rest in the > database. As always things can be discussed, but I would like to have a > good explanation before we support loading any credentials from the vault > into a user or client. > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev >