Skip to content

RestrictUsersAdmission: allow service account with implicit namespace #13649

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

Conversation

Miciah
Copy link
Contributor

@Miciah Miciah commented Apr 6, 2017

Allow role binding restrictions to match and allow a service account subject with an implicit namespace, which is inferred to be the namespace of the role binding.

The use-case for this change is that an application template should be able to specify a role binding with a service account as the subject, without hard-coding the namespace in the template or requiring the user to specify the namespace as a parameter. In this scenario, the subject's namespace gets defaulted to the role binding's namespace, but only after the admission control plug-in executes; the subject that the plug-in sees is a service account with no namespace specified, so RestrictUsersAdmission should infer the namespace to be that the one which will be defaulted later.


Related to https://bugzilla.redhat.com/show_bug.cgi?id=1439065.


openshift-bot, please [test]!

@deads2k, please review!

@abhgupta, FYI.

Allow role binding restrictions to match and allow a service account subject
with an implicit namespace, which is inferred to be the namespace of the role
binding.

The use-case for this change is that an application template should be able to
specify a role binding with a service account as the subject, without
hard-coding the namespace in the template or requiring the user to specify the
namespace as a parameter.  In this scenario, the subject's namespace gets
defaulted to the role binding's namespace, but only after the admission control
plug-in executes; the subject that the plug-in sees is a service account with no
namespace specified, so RestrictUsersAdmission should infer the namespace to be
that the one which will be defaulted later.
@openshift-bot
Copy link
Contributor

Evaluated for origin test up to 8d8b3e4

@openshift-bot
Copy link
Contributor

continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pull_request_origin/593/) (Base Commit: 83e3250)

1 similar comment
@openshift-bot
Copy link
Contributor

continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pull_request_origin/593/) (Base Commit: 83e3250)

@Miciah
Copy link
Contributor Author

Miciah commented Apr 6, 2017

@liggitt, could you review this?

@liggitt
Copy link
Contributor

liggitt commented Apr 6, 2017

lgtm [merge]

@Miciah
Copy link
Contributor Author

Miciah commented Apr 7, 2017

Flake #13662:

[INFO] Validating exec
Running test/end-to-end/core.sh:463: executing 'oc exec -p frontend-1-jt6jq id' expecting success and text '1000'...
Connection to 172.18.10.71 closed by remote host.
++ export status=FAILURE
++ status=FAILURE
+ set +o xtrace
########## FINISHED STAGE: FAILURE: RUN INTEGRATION TESTS ##########

https://ci.openshift.redhat.com/jenkins/job/test_pull_request_origin_integration/884/consoleFull

Failure during provisioning:

TASK [validate-masters : Validate the public address] **************************
Thursday 06 April 2017  22:05:30 +0000 (0:00:00.032)       0:16:57.418 ******** 
FAILED - RETRYING: TASK: validate-masters : Validate the public address (3 retries left).
FAILED - RETRYING: TASK: validate-masters : Validate the public address (2 retries left).
FAILED - RETRYING: TASK: validate-masters : Validate the public address (1 retries left).
fatal: [ci-prtest-5a37c28-828-ig-m-0fbl]: FAILED! => {"attempts": 3, "changed": false, "content": "", "failed": true, "msg": "Status code was not [200]: An unknown error occurred: ''", "redirected": false, "status": -1, "url": "https://api.prtest-5a37c28-828.origin-ci-int-gce.dev.rhcloud.com:443/healthz/ready"}

https://ci.openshift.redhat.com/jenkins/job/test_pull_request_origin_extended_conformance_gce/828/consoleFull

@Miciah
Copy link
Contributor Author

Miciah commented Apr 7, 2017

The second failure could be #13470, although there it's "Request failed: <urlopen error [Errno -2] Name or service not known>" whereas here it's "An unknown error occurred: ''".

@stevekuznetsov
Copy link
Contributor

re[merge] -- queue is healthy again

@stevekuznetsov
Copy link
Contributor

@openshift-bot
Copy link
Contributor

Evaluated for origin merge up to 8d8b3e4

@openshift-bot
Copy link
Contributor

openshift-bot commented Apr 8, 2017

continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_request_origin/291/) (Base Commit: dbcd81b) (Image: devenv-rhel7_6128)

@openshift-bot openshift-bot merged commit 53c0830 into openshift:master Apr 8, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants