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

Allow specifying secret data using strings #28263

Merged
merged 1 commit into from
Jul 1, 2016

Conversation

liggitt
Copy link
Member

@liggitt liggitt commented Jun 30, 2016

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 the data field.

On write, the keys and values in the stringData field are merged to the data map, overwriting any values already present in the data map. The move is one-way, the stringData field is never output when reading from the API.

A Secret can be created like this:

{
  "kind":"Secret",
  "apiVersion":"v1",
  "metadata":{"name":"mysecret"},
  "data":{
    "image":"<base64-encoded-jpg>"
  },
  "stringData":{
    "username": "myuser",
    "password": "mypassword"
  }
}

and when read from the API would look like this:

{
  "kind":"Secret",
  "apiVersion":"v1",
  "metadata":{"name":"mysecret",...},
  "data":{
    "image":"<base64-encoded-jpg>"
    "username": "bXl1c2Vy",
    "password": "bXlwYXNzd29yZA=="
  }
}

@k8s-github-robot k8s-github-robot added kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API size/L Denotes a PR that changes 100-499 lines, ignoring generated files. release-note-label-needed labels Jun 30, 2016
@@ -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.
Copy link
Contributor

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"`
Copy link
Contributor

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.

@smarterclayton
Copy link
Contributor

I assume you'll apply this in the rest strategy?

@liggitt
Copy link
Member Author

liggitt commented Jun 30, 2016

I applied it in conversion, so that the internal type never has to know stringData exists

@@ -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.
Copy link
Member

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?

Copy link
Member Author

@liggitt liggitt Jun 30, 2016

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)

Copy link
Member

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][]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.

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
.

@liggitt
Copy link
Member Author

liggitt commented Jun 30, 2016

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?

@thockin
Copy link
Member

thockin commented Jun 30, 2016

I like this design better. It's an interesting precedent - write-only fields - but not too bizarre.,

@liggitt liggitt added release-note Denotes a PR that will be considered when it comes time to generate release notes. and removed release-note-label-needed labels Jun 30, 2016
@smarterclayton
Copy link
Contributor

smarterclayton commented Jun 30, 2016 via email

@smarterclayton
Copy link
Contributor

smarterclayton commented Jun 30, 2016 via email

@ncdc
Copy link
Member

ncdc commented Jun 30, 2016

@liggitt test case?

@liggitt
Copy link
Member Author

liggitt commented Jun 30, 2016

oops, had one and forgot to push it

@ncdc
Copy link
Member

ncdc commented Jun 30, 2016

@bgrant0607 @thockin @smarterclayton are we in agreement that we can move forward with this?

@liggitt liggitt force-pushed the stringdata branch 2 times, most recently from ef338a0 to 993ab1d Compare June 30, 2016 20:03
@k8s-bot
Copy link

k8s-bot commented Jun 30, 2016

GCE e2e build/test passed for commit 993ab1d.

@bgrant0607
Copy link
Member

Thanks @liggitt @ncdc @smarterclayton. Yes, I'm happy with this approach.

@ncdc
Copy link
Member

ncdc commented Jun 30, 2016

@sjenning can you prep a backport POC of this to your origin (it replaces the other string: secrets PR)?

@smarterclayton
Copy link
Contributor

Lgtm

@smarterclayton smarterclayton added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jun 30, 2016
@thockin
Copy link
Member

thockin commented Jun 30, 2016

SGTM

On Thu, Jun 30, 2016 at 2:31 PM, Clayton Coleman notifications@github.com
wrote:

Lgtm


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

@k8s-github-robot
Copy link

@k8s-bot test this [submit-queue is verifying that this PR is safe to merge]

@k8s-bot
Copy link

k8s-bot commented Jul 1, 2016

GCE e2e build/test passed for commit 993ab1d.

@k8s-github-robot
Copy link

Automatic merge from submit-queue

@k8s-github-robot k8s-github-robot merged commit 34244ef into kubernetes:master Jul 1, 2016
@liggitt liggitt deleted the stringdata branch July 11, 2016 02:23
@transitive-bullshit
Copy link

Is this available in the current version of k8? if so, is it documented anywhere?

@liggitt
Copy link
Member Author

liggitt commented Mar 8, 2017

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:
https://kubernetes.io/docs/api-reference/v1/definitions/#_v1_secret

@transitive-bullshit
Copy link

awesome -- missed that!

@wilmayeung
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API lgtm "Looks good to me", indicates that a PR is ready to be merged. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.