-
Notifications
You must be signed in to change notification settings - Fork 40k
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
Allow specifying secret data using strings #28263
Conversation
@@ -3089,6 +3089,13 @@ type Secret struct { | |||
// Described in https://tools.ietf.org/html/rfc4648#section-4 | |||
Data map[string][]byte `json:"data,omitempty" protobuf:"bytes,2,rep,name=data"` | |||
|
|||
// StringData allows specifying non-binary secret data in string form. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
API convention doc "stringData" as swagger reader would see it
// All keys and values are moved to the data field on write. | ||
// It is never output when reading from the API. | ||
// +genconversion=false | ||
StringData map[string]string `json:"stringData,omitempty" protobuf:"bytes,4,rep,name=stringData"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tag 4 is correct (note to other reviewers) since this is a net new field in proto.
I assume you'll apply this in the rest strategy? |
I applied it in conversion, so that the internal type never has to know |
@@ -3089,6 +3089,13 @@ type Secret struct { | |||
// Described in https://tools.ietf.org/html/rfc4648#section-4 | |||
Data map[string][]byte `json:"data,omitempty" protobuf:"bytes,2,rep,name=data"` | |||
|
|||
// StringData allows specifying non-binary secret data in string form. | |||
// It is provided as a write-only convenience method. | |||
// All keys and values are moved to the data field on write. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/moved/merged/ ? I assume it merges if you have both fields. Who wins in case of colliding keys?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, merged. stringData wins... it never exists when reading from the server, so any time it's set in a request to the server, the caller must have added it. that also lets patch work as intended (you can patch a field in either map and it takes effect)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant "update the comment" with that info :)
On Wed, Jun 29, 2016 at 8:28 PM, Jordan Liggitt notifications@github.com
wrote:
In pkg/api/v1/types.go
#28263 (comment)
:@@ -3089,6 +3089,13 @@ type Secret struct {
// Described in https://tools.ietf.org/html/rfc4648#section-4
Data map[string][]bytejson:"data,omitempty" protobuf:"bytes,2,rep,name=data"
- // StringData allows specifying non-binary secret data in string form.
- // It is provided as a write-only convenience method.
- // All keys and values are moved to the data field on write.
yeah, merged. stringData wins... it's write-only, so any time you specify
it, you're saying you want it. that lets patch work as intended (you can
patch a field in either map and it takes effect)—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/kubernetes/pull/28263/files/ca0c1ab6efc5ab4ed34d3fcdeb5c126007fb4320#r69064660,
or mute the thread
https://github.com/notifications/unsubscribe/AFVgVPALGQmILLBCiC46qquBldHsmJZLks5qQzfhgaJpZM4JBwt9
.
I could add the field to the internal type as well, and add validation, and apply it in BeforeCreate/BeforeUpdate, but I wasn't sure I wanted that field around internally... any strong reason not to do it in conversion? |
I like this design better. It's an interesting precedent - write-only fields - but not too bizarre., |
Agreed, write only isn't as bizarre as I was afraid of.
|
That's fine, I guess it only means validation is a bit wierd until we
do validation on external types.
|
@liggitt test case? |
oops, had one and forgot to push it |
@bgrant0607 @thockin @smarterclayton are we in agreement that we can move forward with this? |
ef338a0
to
993ab1d
Compare
GCE e2e build/test passed for commit 993ab1d. |
Thanks @liggitt @ncdc @smarterclayton. Yes, I'm happy with this approach. |
@sjenning can you prep a backport POC of this to your origin (it replaces the other string: secrets PR)? |
Lgtm |
SGTM On Thu, Jun 30, 2016 at 2:31 PM, Clayton Coleman notifications@github.com
|
@k8s-bot test this [submit-queue is verifying that this PR is safe to merge] |
GCE e2e build/test passed for commit 993ab1d. |
Automatic merge from submit-queue |
Is this available in the current version of k8? if so, is it documented anywhere? |
Yes, it has been available for several releases. It is documented in the API documentation: |
awesome -- missed that! |
The drawback of this approach is any secrets using stringData would be recognized as changed and a patch is needed when calling kubectl apply. Hence always resulted in "configured" even when nothing was changed. |
This PR allows specifying non-binary data values in
Secret
objects as"stringData":{"key":"string value"}
, in addition to the existing base64 []byte serializations in thedata
field.On write, the keys and values in the
stringData
field are merged to thedata
map, overwriting any values already present in thedata
map. The move is one-way, thestringData
field is never output when reading from the API.A Secret can be created like this:
and when read from the API would look like this: