Can a kubernetes member verify that this patch is reasonable to test? If so, please reply with "ok to test" on its own line.

Regular contributors should join the org to skip this step.

While we transition away from the Jenkins GitHub PR Builder plugin, "ok to test" commenters will need to be on the admin list defined in this file.

@kubernetes/sig-api-machinery

The OP is trying to encrypt secrets stored in etcd. He is doing this by adding encryption to the etcd layer. I think he probably wants to do this in such a way that (1) it only encrypts secrets, and not other resources, and (2) so that it is independent of what storage layer is used (e.g. encrypt the json or proto message, or a portion of it) rather than being built into etcd. Can someone such as @lavalamp or @smarterclayton or @deads2k who knows this code well suggest where to plug in?

Another consideration: it might be better to have an outer message that is in cleartext, that tells you just metadata about the stored object (name, kind, version), and only encrypt what needs to be encrypted.

One way to do this is to wrap all storage objects. I think @lavalamp knows about a plan to do that: not sure if it got implemented. It was needed for protocol buffer storage, I think.

Another way to do it is to add a new field to secrets called encryptedData, and to have data be set when using the REST api, but move the keys to encryptedData when preparing to store the object, in PrepareForCreate and PrepareForUpdate, and move them back to data in a new "PrepareForGet" method?

Can someone such as @lavalamp or @smarterclayton or @deads2k who knows this code well suggest where to plug in?

It could be modeled as a storage.Interface which acts a filter on the original storage.Interface. That could be wired up with a generic.StorageDecorator without touching most of the code.

That would let you encrypt before passing to storage and then decrypted before any caching layer saw it.

I agree that this should be built on top storage layer instead of coupling another encryption field into it.

Another problem is that the interface intends to operate on opaque bytes:

    Encrypt(obj string) (string, error)
    Decrypt(encryptedObj string) (string, error)

Unfortunately, the storage layer understands k8s objects and operates on objects. If we want to operate on bytes to/from etcd, another KV layer needs to be refactored out.

So then there should be 2 approaches to this feature? One is to refactor out the storage layer that understands k8s objects and operates on objects and the second is to create a generic.StorageDecorator to handle the encryption / decryption?

I'm happy to do the work, just need some additional help to get started I think in the codebase. It's getting more clear to me, but still new to it all.

@smarterclayton and I have a design (ish) in mind for this already. I haven't looked at this PR yet (very behind on PR reviews right now, sorry), but please don't do a lot of work on it until we agree on the approach. This should be done in the codec/serializer machinery, not the storage layer, and is probably blocked until we start storing in protobuf format (current target 1.5).

OK thanks @lavalamp, @smarterclayton and I did have a discussion a week or so ago about it, but I do see how my current implementation needs some love.

Happy to have a discussion regarding, I think when Clayton and I spoke last, he thought the codec way might of been the wrong place, but again, good to discuss.

What should my next steps be?

Can you make it to an API Machinery SIG meeting? That's probably the best
place to talk about this.

On Tue, Sep 13, 2016 at 12:57 PM, Steve Sloka [email protected]
wrote:

OK thanks @lavalamp https://github.com/lavalamp, @smarterclayton
https://github.com/smarterclayton and I did have a discussion a week or
so ago about it, but I do see how my current implementation needs some
love.

Happy to have a discussion regarding, I think when Clayton and I spoke
last, he thought the codec way might of been the wrong place, but again,
good to discuss.

What should my next steps be?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#32579 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAnglkD9w0RFQRbXvvs2mf9RGbZRd_8bks5qpwARgaJpZM4J7zZ7
.

Sure thing, I just jointed the google group. When is the next meeting?

Tomorrow, 11 AM PDT-- you should have a calendar invite after joining the
group.

On Tue, Sep 13, 2016 at 1:09 PM, Steve Sloka [email protected]
wrote:

Sure thing, I just jointed the google group. When is the next meeting?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#32579 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAnglvEElfQnPtCl7JlftyC8Tj-kK9vCks5qpwMXgaJpZM4J7zZ7
.

Discussion happened today on sig-node. We bounced around a bit. The overall conclusion is that @smarterclayton and I have heard from users that this is desirable and a useful checkbox.

There was further discussion on how to implement it and how the work @hongchaodeng is looking to do with the storage/index design #29888 may be necessary to create an implementation where the object can be encrypted/opaque while still being query-able for labels etc. There was also discussion of using the protobuf envelope feature by @smarterclayton.

Generally it was agreed that we should try and get the storage refactor and protobuf work in regardless and that this is a nice to have on top of those already necessary changes.

@stevesloka volunteered to do the work but he would need our support to make it happen in v1.5. We are also still focused on v1.4 so Steve knows to not expect much action for a week or more here.

@stevesloka PR needs rebase

Adding label:do-not-merge because PR changes docs prohibited to auto merge
See http://kubernetes.io/editdocs/ for information about editing docs

keep open

@stevesloka @philips this is a very desirable feature, what's the status of this PR?, is it forgotten?

@fernandofederico1984 No it's not forgotten, the holidays and my time have been distracted by other things. There's a design doc here: https://docs.google.com/document/d/1lFhPLlvkCo3XFC2xFDPSn0jAGpqKcCCZaNsBAv8zFdE

I've been working with @andrewsykim on the design doc a bit. I think we need to get it into the sig meeting and have a discussion. I mentioned before I'm happy to do the work.

I'll bring this up to the SIG group and see if we can have a discussion on it so we can keep it moving.

Thanks! @stevesloka added some comments in the document.

[APPROVALNOTIFIER] Needs approval from an approver in each of these OWNERS Files:

• docs/OWNERS
• hack/OWNERS
• pkg/OWNERS

We suggest the following people:
cc @brendandburns @eparis
You can indicate your approval by writing /approve in a comment
You can cancel your approval by writing /approve cancel in a comment

Just an FYI, I'm planning on sitting on this PR for a while, sorry... holler if that doesn't work for you. I put the keep open label on.

I'd like to go over the design doc first before I dig into this.

But this quarter is just really packed for me.

@lavalamp @stevesloka and I are currently refactoring the design doc, we agreed that its most likely best if we break this feature up into smaller PRs, we'll report back here when we're done changing up the design doc and if any new PRs come up. :) (don't want to make you do any extra work)

This PR was rolled up into a newer PR - closing.

@smarterclayton which PR?

Nevermind. #41939