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
pass an internal pod object to SCC admission control so it works #14891
Conversation
|
[test] |
|
[testextended][extended:core(builds)] |
|
@smarterclayton @deads2k ptal, i had to undo a bit of the v1 changes @smarterclayton made because the SCC admission controller only likes internal objects. |
|
Evaluated for origin test up to d186041 |
|
Evaluated for origin testextended up to d186041 |
| @@ -112,27 +112,27 @@ func (bs *SourceBuildStrategy) CreateBuildPod(build *buildapi.Build) (*v1.Pod, e | |||
| func (bs *SourceBuildStrategy) canRunAsRoot(build *buildapi.Build) bool { | |||
| var rootUser int64 | |||
| rootUser = 0 | |||
| pod := &v1.Pod{ | |||
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.
Scary
|
Did this fail closed or fail open? |
|
Open :(
Hence my adding a new conformance test.
But i did wonder if it implies the admission controller is fundamentally
flawed. I think the answer is no, though.
Ben Parees | OpenShift
…On Jun 26, 2017 7:33 PM, "Clayton Coleman" ***@***.***> wrote:
Did this fail closed or fail open?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#14891 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEvl3pOQX3RudOmA5su7rmS5IBT_tPvcks5sID-2gaJpZM4OF8xg>
.
|
|
We should probably fail closed in SCC on a known set of resources if
the object type is not recognized
|
w/ the known set being the internal versions of all the resources in k8s+openshift? doesn't the admission controller get called on every create of every resource, or is the chain smarter than that? (that's why i decided the admission controller is probably right as is, because the alternative seems awkward and we really only ran into this situation because we're sort of abusing the admission controller) |
|
continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pull_request_origin/2667/) (Base Commit: 955efb1) (PR Branch Commit: d186041) |
|
continuous-integration/openshift-jenkins/testextended SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pull_request_origin_extended/750/) (Base Commit: 955efb1) (PR Branch Commit: d186041) (Extended Tests: core(builds)) |
|
We already check for resource and subresource. Failing closed on the conversion seems like the right thing to do here. #14901 |
you mean switch the way we are checking if the user can run as root? no, can you open one and put some details/pointers in about what we should be using instead (and then assign it to me). |
Opened #14909 with a link to the API type. |
|
continuous-integration/openshift-jenkins/merge Waiting: You are in the build queue at position: 8 |
|
Evaluated for origin merge up to d186041 |
Automatic merge from submit-queue (batch tested with PRs 15162, 14901, 15195) fail closed on versioned pods We already check the resource and subresource. If we cannot convert to the internal pod type then we should fail. Note: this should not happen during the normal admission process but could happen if someone manually integrates with the admission controller - as in the instance of builds. Ref: #14891 ## Note must merge after #14891 and must be backported as a group if backports are desired
https://bugzilla.redhat.com/show_bug.cgi?id=1464356
bug 1464356