rdns, past and future

[Simo Sorce]

On Wed, 2020-05-27 at 11:59 -0600, Ken Dreyer wrote:
> On Tue, May 26, 2020 at 4:59 PM Jeffrey Altman
> <jaltman at secure-endpoints.com> wrote:
> > On 5/26/2020 6:31 PM, Ken Dreyer wrote:
> > > On Tue, May 26, 2020 at 3:58 PM Jeffrey Altman
> > > <jaltman at secure-endpoints.com> wrote:
> > > >  2. Before the existence of DNS SRV records, CNAME records were the
> > > >     only method of offering a service on multiple hosts.  However,
> > > >     its a poor idea to share the same key across all of the hosts.
> > > 
> > > I'm curious about this. What makes it a poor idea?
> > > 
> > > It seems like a very convenient way to scale a service up and down
> > > dynamically quickly when you share a key among all instances.
> > 
> > Because if you hack into one of the hosts you now have the key for all
> > of the hosts.  The holder of the key can forge tickets for any user.
> 
> This is true only if the administrator has enabled constrained
> delegation for that key (eg. ok_to_auth_as_delegate) right? Is there
> some other scenario I'm missing?

If you own a service key, you can forge a ticket from any user to
yourself without any issue. This of course is not an issue, as there is
no point in breaking into yourself.

If multiple services use the same key then you can forge tickets by any
user to any those services if you stole the common key. This is now a
bad thing because you can jump from one system to another at this
point.

That said, in the kubernetes case, the multiple services are *not*
actually distinct services, they are generally a single service
implemented by multiple containers for scaling purposes. For all intent
and purposes in a kubernets environment sharing the key is not as
disastrous. Once you break into one container you already broke into
that service layer as a whole as you usually get access to other shared
keys (database access for example).

> > Since the key isn't unique the entire distributed service has to be
> > shutdown to address the vulnerability.
> 
> Ok, that makes sense. I was thinking of a homogeneous environment
> where each app server runs the exact same versions of code, so an
> attacker entry through a vulnerability on one system means that all
> systems almost certainly have the same vulnerability.

Exactly, in the special case where sharing happens within the confines
of the same security domain essentially for scaling reasons, you can
definitely make the choice of sharing keys.

> > It is also much harder to trace where the key was stolen from.
> 
> Yeah, that's fair.

In kubernetes you usually have better telemetry than classic systems,
and is normally remoted from the stateless container, which means it is
much harder to alter to cover tracks, so perhaps this concern/risk can
also be better managed there, if you care for it.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc