-
Notifications
You must be signed in to change notification settings - Fork 692
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
Accept and seal stringData into secret #221
Conversation
cmd/kubeseal/main.go
Outdated
} | ||
for key, values := range secret.StringData { | ||
secret.Data[key] = []byte(values) | ||
delete(secret.StringData, key) |
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.
What is the reasoning for deleting the values? Just curious. :)
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.
It is my obsession with doing thinks right. When for example someone latter would serialize this object it will get duplicate fileds in both data
and stringData
sections if delete is not done. I agree it is very improbable and actualy technicaly unnecessary.
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.
When I was first thinking of this issue I though we should make kubeseal take a secret that contains stringData as input, produce a sealed secret that once converted into a secret would be identical to the original, namely keeping the stringData intact. This means we would have to somehow encode that in the sealed secret CRD schema.
But this approach seems pragmatic enough. I wonder how would backwards compatibility look like if we later decide that reversibility is important.
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.
Makes good sense. Could a test for this maybe be usefull for future reference? So the behaviour becomes very explicit?
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'm not sure I can write right now more complicated test suite in go (this is my second commit in go ... :). But if You give me a hint I will try.
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.
Actually kubectl does the same operation, data and stringData cannot be distinguished once pushed into Kubernetes api.
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.
Ah interesting, didn't know (fwiw I'm not fond of this kind of magic in k8s...).
Happy to merge when we have some tests
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 have managed to dig this think a bit deeper and add some test, please check if it is enought. The whole thing have changed.
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.
The TestSealRoundTripStringDataConversion is more or less duplicate of TestSealRoundTrip, so mey be keep only one of those?
c591d1c
to
e25eae4
Compare
bors r+ |
221: Accept and seal stringData into secret r=mkmik a=pinkavaj Ref #104 Co-authored-by: Jiri Pinkava <[email protected]>
Build succeeded |
Ref #104