Data privacy in KDC

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Data privacy in KDC

Yegui Cai
Hi all.

I have some questions regarding data privacy in KDC.
1. If I have multiple tenants sharing the same KDC (say, a tenant is mapped
into a realm), how KDC make sure that the data is segregated between realms?
2. Similar questions regarding logs. Is there any way to segregate logs
between different realms?
3. If I use the default data storage (Berkeley DB if my understanding is
correct), how data is encrypted at rest?

Thanks a lot!
Yegui Cai
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Data privacy in KDC

Greg Hudson
On 3/4/19 11:45 AM, Yegui Cai wrote:
> 1. If I have multiple tenants sharing the same KDC (say, a tenant is mapped
> into a realm), how KDC make sure that the data is segregated between realms?

The best option is probably to run separate KDC processes for each
realm, with each process listening to a different port.

It is possible for a single KDC process to serve multiple realms, but it
is not a common configuration, and kadmind doesn't have the same
facility.  In this configuration, each realm still has its own separate
database, and the KDC will only access the database for the request that
is currently processing (based on the realm field of the KDC-REQ-BODY).

> 2. Similar questions regarding logs. Is there any way to segregate logs
> between different realms?

With separate KDC processes, each can have its own kdc.conf file with
different [logging] directives.

With one KDC process serving multiple realms, I don't believe there is
any way to keep the logs separate.

> 3. If I use the default data storage (Berkeley DB if my understanding is
> correct), how data is encrypted at rest?

Principal long-term keys are encrypted in a master key; the master key
is typically located in a stash file separate from the KDB so that it
can be backed up more securely (or not at all).  Other principal
metadata is not encrypted.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Data privacy in KDC

Yegui Cai
Hi Greg.
Thanks a lot for your reply.

A further question regarding 3. The database files (principle,
principal.kadm5) are not encrypted, am I right?

Best,
Yegui

On Mon, Mar 4, 2019 at 12:16 PM Greg Hudson <[hidden email]> wrote:

> On 3/4/19 11:45 AM, Yegui Cai wrote:
> > 1. If I have multiple tenants sharing the same KDC (say, a tenant is
> mapped
> > into a realm), how KDC make sure that the data is segregated between
> realms?
>
> The best option is probably to run separate KDC processes for each
> realm, with each process listening to a different port.
>
> It is possible for a single KDC process to serve multiple realms, but it
> is not a common configuration, and kadmind doesn't have the same
> facility.  In this configuration, each realm still has its own separate
> database, and the KDC will only access the database for the request that
> is currently processing (based on the realm field of the KDC-REQ-BODY).
>
> > 2. Similar questions regarding logs. Is there any way to segregate logs
> > between different realms?
>
> With separate KDC processes, each can have its own kdc.conf file with
> different [logging] directives.
>
> With one KDC process serving multiple realms, I don't believe there is
> any way to keep the logs separate.
>
> > 3. If I use the default data storage (Berkeley DB if my understanding is
> > correct), how data is encrypted at rest?
>
> Principal long-term keys are encrypted in a master key; the master key
> is typically located in a stash file separate from the KDB so that it
> can be backed up more securely (or not at all).  Other principal
> metadata is not encrypted.
>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos