[keycloak-dev] Suggestion of fields covered by Vault SPI
Stian Thorgersen
sthorger at redhat.com
Mon Aug 26 03:24:41 EDT 2019
Encrypting secrets at rest is a harder problem, which will be tackled next.
The most important thing to resolve now is the issue users have complained
about which is LDAP credentials and SMTP credentials in clear text in the
dB. The read-only vault solves that issue in a efficient, simple and secure
way.
On Fri, 23 Aug 2019, 15:51 Pedro Igor Silva, <psilva at redhat.com> wrote:
> 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
>>
>
More information about the keycloak-dev
mailing list