Hi James, On Wed, Mar 13, 2019 at 08:36:34AM -0700, James Bottomley wrote: > On Wed, 2019-03-13 at 11:16 -0400, Theodore Ts'o wrote: > > So before we talk about how to make things work from a technical > > perspective, we should consider what the use case happens to be, and > > what are the security requirements. *Why* are we trying to use the > > combination of overlayfs and fscrypt, and what are the security > > properties we are trying to provide to someone who is relying on this > > combination? > > I can give one: encrypted containers: > > https://github.com/opencontainers/image-spec/issues/747 > > The current proposal imagines that the key would be delivered to the > physical node and the physical node containerd would decrypt all the > layers before handing them off to to the kubelet. However, one could > imagine a slightly more secure use case where the layers were > constructed as an encrypted filesystem tar and so the key would go into > the kernel and the layers would be constructed with encryption in place > using fscrypt. > > Most of the desired security properties are in image at rest but one > can imagine that the running image wants some protection against > containment breaches by other tenants and using fscrypt could provide > that. > What do you mean by "containment breaches by other tenants"? Note that while the key is added, fscrypt doesn't prevent access to the encrypted files. fscrypt is orthogonal to OS-level access control (UNIX mode bits, ACLs, SELinux, etc.), which can and should be used alongside fscrypt. fscrypt is a storage encryption mechanism, not an OS-level access control mechanism. - Eric
