[keycloak-dev] Suggestion of fields covered by Vault SPI

[Pedro Igor Silva]

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 at redhat.com>
wrote:

> On Fri, 23 Aug 2019 at 12:11, Michal Hajas <mhajas at redhat.com> wrote:
>
> > Thank you for responding Stian. Comments below.
> >
> > On Thu, Aug 22, 2019 at 1:58 PM Stian Thorgersen <sthorger at redhat.com>
> > 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>