Flyte-core define pod and container securityContext #4809
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dosubot
bot
added
size:L
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #4809 +/- ##
==========================================
+ Coverage 58.98% 59.73% +0.74%
==========================================
Files 644 644
Lines 55146 49161 -5985
==========================================
- Hits 32529 29364 -3165
+ Misses 20043 17223 -2820
Partials 2574 2574
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
This one looks very interesting. @ddl-ebrown have you already deployed the chart with these settings?
|
We have and everything starts ok BUT we haven't yet validated everything works ok. We'll be doing that this week and I'll follow up. Unlike the agent where you've got a general purpose chart capable of deploying a bunch of different agents, you control all of the code in all of these services so I thought for now there's less of a need for these settings to be configurable. I'm not sure what your integration test suites do, but if they exercise the majority of the Flyte features then that should be some signal that these changes are compatible |
- Define secure defaults for all pod / container specs:
* runAsNonRoot: true
* capabilities:
drop: ['ALL']
* allowPrivilegeEscalation: false
* seLinuxOptions:
type: spc_t
This is required in many locations where policy enforcement agents
may be installed (like OPA Gatekeeper) which may otherwise prevent
deployments from launching.
The hard work of making sure the containers run as non-0 uids seems
to have already been done given all containers are already specifying
a runAsUser value of 1000 or 1001, so this should hopefully just be a
little more hardening around restricting kernel permissions /
enforcement within the container runtime.
These are generally considered standard / secure default settings and
are not currently made configurable given these services are all
owned by Flyte
Signed-off-by: ddl-ebrown <[email protected]>
ddl-ebrown
force-pushed
the
improve-flytecore-securitycontext
branch
from
1610086 to
a3ffa89
Compare
katrogan
pushed a commit
that referenced
this pull request
Feb 20, 2024
- Define secure defaults for all pod / container specs:
* runAsNonRoot: true
* capabilities:
drop: ['ALL']
* allowPrivilegeEscalation: false
* seLinuxOptions:
type: spc_t
This is required in many locations where policy enforcement agents
may be installed (like OPA Gatekeeper) which may otherwise prevent
deployments from launching.
The hard work of making sure the containers run as non-0 uids seems
to have already been done given all containers are already specifying
a runAsUser value of 1000 or 1001, so this should hopefully just be a
little more hardening around restricting kernel permissions /
enforcement within the container runtime.
These are generally considered standard / secure default settings and
are not currently made configurable given these services are all
owned by Flyte
Signed-off-by: ddl-ebrown <[email protected]>
Signed-off-by: Katrina Rogan <[email protected]>
yubofredwang
pushed a commit
to yubofredwang/flyte
that referenced
this pull request
Mar 26, 2024
- Define secure defaults for all pod / container specs:
* runAsNonRoot: true
* capabilities:
drop: ['ALL']
* allowPrivilegeEscalation: false
* seLinuxOptions:
type: spc_t
This is required in many locations where policy enforcement agents
may be installed (like OPA Gatekeeper) which may otherwise prevent
deployments from launching.
The hard work of making sure the containers run as non-0 uids seems
to have already been done given all containers are already specifying
a runAsUser value of 1000 or 1001, so this should hopefully just be a
little more hardening around restricting kernel permissions /
enforcement within the container runtime.
These are generally considered standard / secure default settings and
are not currently made configurable given these services are all
owned by Flyte
Signed-off-by: ddl-ebrown <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Like #4785 does for the agent, this defines the security context for flyte-core pods / containers.
Define secure defaults for all pod / container specs:
This is required in many locations where policy enforcement agents
may be installed (like OPA Gatekeeper) which may otherwise prevent
deployments from launching.
The hard work of making sure the containers run as non-0 uids seems
to have already been done given all containers are already specifying
a runAsUser value of 1000 or 1001, so this should hopefully just be a
little more hardening around restricting kernel permissions /
enforcement within the container runtime.
These are generally considered standard / secure default settings and
are not currently made configurable given these services are all
owned by Flyte
Tracking issue
https://github.com/flyteorg/flyte/issues/
Why are the changes needed?
What changes were proposed in this pull request?
How was this patch tested?
In local testing, all pods seem to be behaving correctly with these additional restrictions
Setup process
Screenshots
Check all the applicable boxes
Related PRs
Docs link