-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Pod Security Option support and Infra Inheritance changes #12208
Conversation
e17296f
to
d03eb0e
Compare
d03eb0e
to
95a321c
Compare
95a321c
to
40a2b43
Compare
bbdf94a
to
52c829e
Compare
14154c6
to
1b1866d
Compare
@mheon any idea why the play kube seccomp tests are failing? looks like something that is not supposed to be permitted is being allowed. Could this be something that doesn't apply now since security options are allowed? |
0e49ee8
to
2215e29
Compare
Can you link a failure? Gitvalidation is failing now, so I can't see the failures |
@mheon here is a link: https://storage.googleapis.com/cirrus-ci-6707778565701632-fcae48/artifacts/containers/podman/6536676483792896/html/int-podman-fedora-33-rootless-host.log.html I am pushing now to fix the validation, trying something new to see if that fixes the seccomp issues EDIT: seeing same failures in most recent test runs. |
2215e29
to
121d066
Compare
It's complaining we don't have a private mount namespace? Error is coming out of crun, definitely, but I think we're passing an invalid config - I don't see how Podman can create a container without a private mount namespace though. |
I think you're mangling the spec such that we no longer have a mount namespace, but I'm not sure how that's happening. Maybe we're trying to inherit the pod's mount namespace? |
6d24cd2
to
5cd899b
Compare
@containers/podman-maintainers PTAL I think this is good to go |
While you are in fixing the SELinux check could you add a --security-opt seccomp=unconfined check, also. |
the seccomp=unconfined is in the first test, I do it simultaneously with label=type:spc_t @rhatdan |
63b0f4a
to
6c31371
Compare
@containers/podman-maintainers PTAL |
6c31371
to
5c51adb
Compare
LGTM |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cdoern, rhatdan The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@containers/podman-maintainers PTAL |
} | ||
} | ||
if compatibleOptions != nil { | ||
options = append(options, libpod.WithInfraConfig(*compatibleOptions)) |
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.
Instead of doing this, can we return the InfraInherit and do the unmarshal over the spec within pkg/specgen/generate/oci.go as we create the spec itself? Localizes the changes to pkg/spec which seems simpler, though you will have to pass the InfraInherit around a bit
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, it looks like you're passing it into SpecGenToOCI below, so it probably isn't even necessary to change how it's passed around
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.
so is this good as is? theSpecGenToOCI
bit is just for config elements that get overwritten. This works for like 90% of options.
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'd prefer to remove the option and just set the values in the spec in SpecGenToOCI - most options alter more than just the spec, if we're just changing the spec we can do it during spec generation
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.
ok, I am trying to have this just be done in the spec, but for some reason all of the tests are failing even though the runtime spec has the proper values. I am going to investigate a bit,
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.
Huh...
Can you verify if it has the correct values after it gets put into the DB? I wonder if some other part of container creation is overwriting it.
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.
ok @mheon I did some digging, I do not think the issue is with the runtime spec, I think the container config needs to be modified as well. some options like volumes are not explicitly in the spec and will be dropped.
Instead of doing options, I could make a path that opts to do something like a checkpoint where we load the config from infra (or at least what matches). Could help delineate this from regular create options
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.
OK, if we need config changes, options are fine - I'd just prefer to keep things split (the options modify the container config, while state modification is done without options in SpecGen). Doesn't need to be more than one option, either - the old approach of a single option to grab all relevant config blobs from the infra works fine in my book.
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.
ok @mheon, then is this PR good as is? I never pushed the new changes.
@cdoern Back in your hands. |
sorry I will circle back to this later tonight. |
5c51adb
to
9385749
Compare
@containers/podman-maintainers PTAL |
9385749
to
bc0e45b
Compare
Added support for pod security options. These are applied to infra and passed down to the containers as added (unless overridden). Modified the inheritance process from infra, creating a new function Inherit() which reads the config, and marshals the compatible options into an intermediate struct `InfraInherit` This is then unmarshaled into a container config and all of this is added to the CtrCreateOptions. Removes the need (mostly) for special additons which complicate the Container_create code and pod creation. resolves containers#12173 Signed-off-by: cdoern <[email protected]>
bc0e45b
to
2892703
Compare
@mheon PTAL |
/lgtm |
What this PR does / why we need it:
Added support for pod security options. These are applied to infra and passed down to the
containers as added (unless overridden).
Modified the inheritance process from infra, creating a new function Inherit() which reads the config, and marshals the compatible options into an intermediate struct
InfraInherit
This is then unmarshaled into a container config and all of this is added to the CtrCreateOptions. Removes the need (mostly) for special additions which complicate the Container_create
code and pod creation.
Which issue(s) this PR fixes:
resolves #12173
Signed-off-by: cdoern [email protected]