Service export should handle securityContext field

[dsimansk]

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

[taniaduggal]

I want to work on this issue, can you please tell from where i can start?

[rhuss]

@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!

[Rahul-Kumar-prog]

@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

[dsimansk]

@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

[rhuss]

+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)