knative
Service export should handle securityContext field
Feature request
With more Pod Security Standards enabled clusters we need to address the securityContext being present in PodSpec and Containers definitions. Since the two cluster with different PSS config might not be compatible for the same export.
I'd suggest that we remove it in default behavior and add a flag to include it optionally
UI Example
kn service export <ksvc> --with-securityContext
or
kn service export <ksvc> --with-sc
/kind good-first-issue /kind proposal
/cc @rhuss @mvinkler
I want to work on this issue, can you please tell from where i can start?
@taniaduggal, that is great! Before we start, I would like to discuss this update's background briefly.
I think this story is part of a larger story, where we allow user to filter out certain information when doing an export so that it can be later used in a GitOps scenario.
Besides the securityContext, I can also see fields we should not export by default, e.g. the namespace.
So I suggest that we make a new option flexible so that we can fine granularly specify what to include (if excluded by default) and what to included (if included by default).
My suggestion would be to have an option like
kn service export myservice --include securityContext,namespace
or
kn service export myservice --include securityContext --include namespace
@dsimansk what is your take on this ?
(using multiple options here).
@taniaduggal for starting its best to look at https://github.com/knative/client/blob/main/pkg/kn/commands/service/export.go which has all the logic for an export. This would be the place where we would evaluate that option and do the filtering.
Thanks again @taniaduggal that you want to jump on the train, greatly appreciated!
@rhuss I read you idea and you want that users can filter certain info... that good idea. I have some questions: like: why we should not use
kn service export <ksvc> --with-securityContext
or
kn service export <ksvc> --with-sc
@Rahul-Kumar-prog I'd go with @rhuss's suggestion, the --include flag might be more flexible in the term of adding new known variables, instread of adding the whole new flag, with near infinite growth (hopefully not).
I'd go with this variant. And the valid values are predefined and listed in the help message.
kn service export myservice --include securityContext,namespace
+1 for not use options inflationary but have an easy way to extend this feature without changing the "option API surface". In addition to provide the options as a comma separated list, multiple --include options should also work, like in --include securityContext --include namespace (it then also easy to add shortcuts like --include sc,ns without blowing up the options)
Ok, @rhuss @dsimansk I got your points and rhuss suggestion is perfect to go with. Is there anything else I need to know?
I want to work on this but i am already working on knative-kafka-broker repo issue so after finishing that i would love to work on this if its ok then please let me know.
Thanks! It's totally fine if you want to jump on this issue later, and we can then work on a PR as soon as you have something to share.
+1 @rhuss
Assigning to you @Rahul-Kumar-prog to indicate it's being looked at some point. It's still ~2 months until next release v1.12. There's no time pressure right now. Feel free to proceed at your convenience.
/assign @Rahul-Kumar-prog
