Re: *****SPAM***** RE: Support for additional bind-mounts to specific container types

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





> 
> 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@xxxxxxx
To unsubscribe send an email to ceph-users-leave@xxxxxxx



[Index of Archives]     [Information on CEPH]     [Linux Filesystem Development]     [Ceph Development]     [Ceph Large]     [Ceph Dev]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [xfs]


  Powered by Linux