Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Platform support for SSE (Server-Side Encryption) #1

Open
kingdonb opened this issue Oct 15, 2017 · 1 comment
Open

Platform support for SSE (Server-Side Encryption) #1

kingdonb opened this issue Oct 15, 2017 · 1 comment

Comments

@kingdonb
Copy link
Member

I found that the s3cmd driver for AWS at least looks like it needs a parameter "encrypt" to encrypt bucket contents, parameter should be set to true. This is not a critical fix because the S3 bucket that is managed by wal-e is the only one that should need to be encrypted, but for my department policy will probably require that all three buckets should be encrypted.

(In case somebody slips up and uploads an image or a builder artifact with a key embedded in it. The buckets will all be private, and the release artifacts also private, so we would not usually need to emergency-rotate these keys, but there is always the possibility that someone will slip up and by mistake upload a production key into a git repo or through some Dockerfile ADD, and then they will need to be scheduled to be rotated.)

So, to alleviate this, I wanted to enable encryption on all three buckets via s3-uploader, that way my InfoSec department can enforce full encryption via policy on all of our s3 buckets, and we will never accidentally store unencrypted keys.

Does anyone know about the encryption support across other platforms such as Azure, GCE, Swift? We are on AWS/S3 and I know that Encryption is an optional flag to pass with the PUT. (If we can implement that in a way that supports all existing cloud storage options, I'd expect this to be a welcome change in the trunk.)

@kingdonb
Copy link
Member Author

kingdonb commented Oct 15, 2017

Also related to: deis/workflow#481
deis/workflow#674
deis/workflow#857

If encryption is supported on Minio too, then we should use it... probably optionally with a global.encrypt flag in values.yaml

If not, we don't currently have a persistence story in Minio, so no big deal. There's really no need to store stuff encrypted in-memory.

It would also be good to check on wal-e and see what encryption story looks like across supported platforms here, too... wal-e connects to S3 directly and passes the encrypt flag, but it does not talk through the s3-uploader

So if the user passes global.encrypt then we ought to find a way to honor it, or balk at the setting on the target platform (balk and error)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant