Conversation
openshift-ci-robot
added
size/XXL
…ions for controlling no-new-privs flag. This commit adds two new members to SecurityContextConstraints: * AllowPrivilegeEscalation -- controls whether a container may request privilege escalation or not (by setting SecurityContext.AllowPrivilegeEscalation: true). When SCC doesn't define this member, it defaulted to "true" for backward/Kubernetes compatibility reasons. * DefaultAllowPrivilegeEscalation -- sets default value for container's SecurityContext.AllowPrivilegeEscalation field when it wasn't explicitly specified.
|
@php-coder @wozniakjan here's my attempt at this. we'll see which one makes it. |
| # openshift second | ||
| - package: github.com/openshift/api | ||
| version: 0ce1df2db7debb15eddb25f3ae76df4180777221 | ||
| version: master |
|
Are the original pulls for these already lgtm'd? @openshift/sig-security |
|
glide, api, and generation changes LGTM. defer to build and security teams for the validation and use of the fields |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: bparees, simo5 The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
deads2k
added
the
priority/critical-urgent
|
This is going to make the re-rebase to 1.11 GA much easier. bumping queue priority. |
|
#20157 |
|
#20157 again /retest |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
this is needed for the re-rebase to GA. conformance install was fine. The base level is really close. Nothing here appears to be gcp only. merging. |
|
@bparees: The following test failed, say
DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
|
This PR seems to have broken the logic during upgrades in openshift-ansible - Is it expected or a side-effect of this PR? |
|
I don't see anything in this PR that would have modified that. Are you passing --confirm? |
Weird, this error poped up approximately when this was merged.
No, isn't it ignored now? openshift/openshift-ansible#8781 drops I'll try adding |
that is a separate command. scc reconciliation still requires it. |
|
Adding In this test the upgrade is being run immediately after install, so its not the difference between minor versions. However I can't pinpoint the exact change which caused this, but the timing suggest its this PR |
|
The ansible code that's failing is intended to abort the upgrade if there have been changes to bootstrapped SCCs because if we were to reconcile them we'd stomp on local customizations. So I believe this is an indication that something has changed unexpectedly? |
I misunderstood the question. That code is intentionally doing a dry-run to see if reconciliation is required.
This PR added a new field to the SCCs that meant they needed reconciling. That is not unexpected. Why does that fail an upgrade? |
|
openshift/openshift-ansible#8390 (and some subsequent cleanup) Added the check at the behest of support with feedback from @simo5 |
that appears to be checking SCC reconciliation with an oc version skewed from the API server (new oc, old apiserver), which will emit false positives around reconciliation for this new defaulted field |
9 participants
No description provided.