Repository navigation
Service export should handle securityContext field #1788
Description
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
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
Activity
taniaduggal commentedon May 8, 2023
I want to work on this issue, can you please tell from where i can start?
rhuss commentedon May 12, 2023
@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
or
@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 commentedon Aug 16, 2023
@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
dsimansk commentedon Aug 17, 2023
@Rahul-Kumar-prog I'd go with @rhuss's suggestion, the
--includeflag 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.
rhuss commentedon Aug 17, 2023
+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
--includeoptions should also work, like in--include securityContext --include namespace(it then also easy to add shortcuts like--include sc,nswithout blowing up the options)Rahul-Kumar-prog commentedon Aug 17, 2023
Ok, @rhuss @dsimansk
I got your points and rhuss suggestion is perfect to go with.
Is there anything else I need to know?
Rahul-Kumar-prog commentedon Aug 18, 2023
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.
rhuss commentedon Aug 21, 2023
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.
dsimansk commentedon Aug 21, 2023
+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
EraKin575 commentedon Jun 17, 2024
I would like to take this one
Rahul-Kumar-prog commentedon Jun 17, 2024
Feel free to start working or you can assign it to yourself.
EraKin575 commentedon Jun 21, 2024
/assign
thiagomedina commentedon Aug 25, 2025
/assign