8:51 a.m.
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>
wrote:
On Fri, 23 Aug 2019 at 12:11, Michal Hajas <mhajas(a)redhat.com>
wrote:
> Thank you for responding Stian. Comments below.
>
> On Thu, Aug 22, 2019 at 1:58 PM Stian Thorgersen <sthorger(a)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(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