[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ceph-users
Subject:    [ceph-users] Re: *****SPAM***** RE: Support for additional bind-mounts to specific container types
From:       Marc <Marc () f1-outsourcing ! eu>
Date:       2022-01-30 12:14:12
Message-ID: 2b2b741b90dd4202b955a1418e0914f5 () f1-outsourcing ! eu
[Download RAW message or body]




> 
> Point 1 (Why are we running as root?):
> All Ceph containers are instantiated as root (Privileged - for "reasons")
> but daemons inside the container run a user 167 ("ceph" user).

Pfffff, I was not expecting that at all. In any case if cephadm ever matures, this \
will definitely disappear.

> I don't understand your second point, if you're saying that the
> "container" is what specifies mount points that's incorrect. It's the
> "docker run" instantiation of the container that specifies what mount
> points are passed to the container and that is controlled by "cephadm"
> today.

This is confusing. I thought you were doing some mount from within the container, \
since you mentioned the container upgrade. But if you don't, I can't see how it is a \
problem specifying a volume to your container. I guess it is again something \
unconventional like 'more' of cephadm.

> The length of validity of a mutual TLS certificate means nothing if a
> hacker compromises the key.
> 

How is this relevant to your previous statement about certificate expiration? 

Container environments have sophisticated services to handle secrets. These secrets \
are eg not visible in rootfs of the container or on the host, can be encrypted, are \
designed to be short lived and not to leak. Research what secrets solution docker has \
and use that for keys.





_______________________________________________
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-leave@ceph.io


[prev in list] [next in list] [prev in thread] [next in thread]