Skip to content
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.

Sign up for GitHub

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

Jump to bottom

use cluster role aggregation for admin, edit, and view #17976

Merged
merged 1 commit into from
Jan 16, 2018
Merged

use cluster role aggregation for admin, edit, and view #17976

merged 1 commit into from
Jan 16, 2018

Conversation

deads2k
Copy link
Contributor

@deads2k deads2k commented Jan 3, 2018

Update to use the aggregated admin, edit, and view from upstream.

@openshift/sig-security
@sub-mod fyi

/assign simo5
/assign enj

@openshift-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jan 3, 2018
@openshift-ci-robot openshift-ci-robot added the size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. label Jan 3, 2018
@deads2k
Copy link
Contributor Author

deads2k commented Jan 3, 2018

Oh that's cool. Because integration tests use restricted clients and those no longer have access without the aggregation controller, we don't have project level access without running controllers.

@simo5
Copy link
Contributor

simo5 commented Jan 3, 2018

Am I reading it right that we now stop checking the resulting roles, but only check the additional permission we add to kubes roles ?
I think we should keep checkign the aggregated role as resulting out of the aggregation, and not just the additions we make.

@enj
Copy link
Contributor

enj commented Jan 3, 2018

Oh that's cool. Because integration tests use restricted clients and those no longer have access without the aggregation controller, we don't have project level access without running controllers.

I suppose you could special case the aggregation controller in the integration test master? Seems slightly less ugly than always running controllers.

Am I reading it right that we now stop checking the resulting roles, but only check the additional permission we add to kubes roles ?
I think we should keep checkign the aggregated role as resulting out of the aggregation, and not just the additions we make.

The upstream coverage unit tests handle this partially. @deads2k I assume we will need an integration test to assert the final output of all cluster roles after aggregation?

@deads2k
Copy link
Contributor Author

deads2k commented Jan 3, 2018

The upstream coverage unit tests handle this partially. @deads2k I assume we will need an integration test to assert the final output of all cluster roles after aggregation?

We could. We could also choose to structure our roles to be additive. View gets aggregated into edit and admin. I think it probably makes more sense to do that. In this case, I know what gets added, so rules from both admin roles up and downstream are added for coverage checks. The current unit test is still safe.

I suppose you could special case the aggregation controller in the integration test master? Seems slightly less ugly than always running controllers.

I could. There's a config option for it. I don't feel very strongly. I'll see what's easiest.

@deads2k
Copy link
Contributor Author

deads2k commented Jan 3, 2018

/retest

@enj
Copy link
Contributor

enj commented Jan 4, 2018

We could. We could also choose to structure our roles to be additive. View gets aggregated into edit and admin. I think it probably makes more sense to do that. In this case, I know what gets added, so rules from both admin roles up and downstream are added for coverage checks. The current unit test is still safe.

This handles the coverage case. I would still like an integration test that fails when we rebase on kube and get the new additions to admin, edit and view. From what I can tell, after this PR merges, we will no longer have a bootstrap file that contains the final, fully aggregated value for those cluster roles.

@deads2k
Copy link
Contributor Author

deads2k commented Jan 4, 2018

we will no longer have a bootstrap file that contains the final, fully aggregated value for those cluster roles.

You'll get the individuals, right?

@deads2k
Copy link
Contributor Author

deads2k commented Jan 4, 2018

/retest

soltysh
soltysh reviewed Jan 4, 2018
View reviewed changes
pkg/cmd/server/bootstrappolicy/policy.go
},
},
// a role for a namespace level admin. It is `edit` plus the power to grant permissions to other users.
ObjectMeta: metav1.ObjectMeta{Name: "system:openshift:aggregate-to-admin", Labels: map[string]string{"rbac.authorization.k8s.io/aggregate-to-admin": "true"}},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Finally, I've been waiting for this. Especially when I was trying to figure out the rights changes during 1.8 rebase.

@enj
Copy link
Contributor

enj commented Jan 5, 2018

You'll get the individuals, right?

Right but its the final union I care about. @simo5 WDYT?

@deads2k
Copy link
Contributor Author

deads2k commented Jan 5, 2018

You'll get the individuals, right?
Right but its the final union I care about. @simo5 WDYT?

It will be much easier to manage by splitting it into upstream and downstream. We keep a lid on what's going in upstream. We always separate the bootstrap file update into something rather small in the rebase, that's the place to be inspecting these. Duplicating a role to present a whitelist is kind of silly.

@simo5
Copy link
Contributor

simo5 commented Jan 5, 2018

@deads2k I do not think that double checking the full role is silly.
During rebses people are busy fixing a ton of stuff and things may slip. If you have a test that is explicitly failing you will pay attention to it.

@liggitt
Copy link
Contributor

liggitt commented Jan 5, 2018

I think the diff in the upstream system:aggregate-to-* role is sufficient... that still prompts us to review the changes

@deads2k
Copy link
Contributor Author

deads2k commented Jan 5, 2018

During rebses people are busy fixing a ton of stuff and things may slip. If you have a test that is explicitly failing you will pay attention to it.

It wouldn't have any more attention paid than the diff to the role. Less probably, since it would look like a simple fix up and most people won't even know what the resources being added do. The diff on the list of all roles is a thing we always review and is always reviewed by someone who has a shot at knowing what they all are.

@enj
Copy link
Contributor

enj commented Jan 8, 2018

I will write the integration test for my own sake afterwards.

Otherwise I think you will have to update the TSB bootstrap to use aggregation since they directly update admin/edit/view IIRC.

@openshift-ci-robot
Copy link

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: deads2k

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these OWNERS Files:

You can indicate your approval by writing /approve in a comment
You can cancel your approval by writing /approve cancel in a comment

@openshift-merge-robot openshift-merge-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jan 10, 2018
@openshift-merge-robot openshift-merge-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jan 10, 2018
@deads2k deads2k added the lgtm Indicates that a PR is ready to be merged. label Jan 11, 2018
@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

1 similar comment
@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

@openshift-merge-robot openshift-merge-robot removed the lgtm Indicates that a PR is ready to be merged. label Jan 12, 2018
@deads2k
Copy link
Contributor Author

deads2k commented Jan 12, 2018

/retest

@deads2k deads2k added the lgtm Indicates that a PR is ready to be merged. label Jan 12, 2018
@deads2k
Copy link
Contributor Author

deads2k commented Jan 12, 2018

/retest

1 similar comment
@deads2k
Copy link
Contributor Author

deads2k commented Jan 12, 2018

/retest

@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

2 similar comments
@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

@deads2k
Copy link
Contributor Author

deads2k commented Jan 15, 2018

/retest

@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

@deads2k
Copy link
Contributor Author

deads2k commented Jan 16, 2018

/retest

1 similar comment
@deads2k
Copy link
Contributor Author

deads2k commented Jan 16, 2018

/retest

@openshift-merge-robot
Copy link
Contributor

/test all [submit-queue is verifying that this PR is safe to merge]

@openshift-ci-robot
Copy link

@deads2k: The following tests failed, say /retest to rerun them all:

Test name Commit Details Rerun command
ci/openshift-jenkins/cmd b81b982 link /test cmd
ci/openshift-jenkins/extended_conformance_install b81b982 link /test extended_conformance_install

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Instructions 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.

@openshift-merge-robot
Copy link
Contributor

Automatic merge from submit-queue (batch tested with PRs 17976, 17195, 18093, 18080, 17922).

@openshift-merge-robot openshift-merge-robot merged commit b1c72ce into openshift:master Jan 16, 2018
@dmage dmage mentioned this pull request Jan 17, 2018
Merged
@enj
Copy link
Contributor

enj commented Jan 19, 2018

Otherwise I think you will have to update the TSB bootstrap to use aggregation since they directly update admin/edit/view IIRC.

@deads2k you broke SC https://bugzilla.redhat.com/show_bug.cgi?id=1535639 - pkg/oc/bootstrap/docker/openshift/rbac.go

@deads2k
Copy link
Contributor Author

deads2k commented Jan 22, 2018

Otherwise I think you will have to update the TSB bootstrap to use aggregation since they directly update admin/edit/view IIRC.
@deads2k you broke SC https://bugzilla.redhat.com/show_bug.cgi?id=1535639 - pkg/oc/bootstrap/docker/openshift/rbac.go

Ouch. Someone was trying to manipulate role subject to reconciliation?

@jboyd01 jboyd01 mentioned this pull request Jan 23, 2018
Merged
@deads2k deads2k deleted the rbac-7-aggregate branch January 24, 2018 14:30
openshift-merge-robot added a commit that referenced this pull request Jan 25, 2018
@openshift-merge-robot
Merge pull request #18251 from jboyd01/catalog-cluster-role-aggrigation
b7649fe 
Automatic merge from submit-queue (batch tested with PRs 18191, 18264, 18235, 18251, 18271).

Use cluster role aggregation for service catalog RBAC

fixes https://bugzilla.redhat.com/show_bug.cgi?id=1535639

follow on from #17976
@danwinship danwinship mentioned this pull request Jan 31, 2018
Merged
openshift-merge-robot added a commit that referenced this pull request Feb 1, 2018
@openshift-merge-robot
Merge pull request #18372 from danwinship/fix-networkpolicy-rbac-policy
45446c3 
Automatic merge from submit-queue (batch tested with PRs 18044, 18372, 18354).

Re-fix NetworkPolicy bootstrap policies

#17976 "use cluster role aggregation for admin, edit, and view" removed permission for "admin" and "edit" on extensions.NetworkPolicy (but not networking.NetworkPolicy). It appears to have been a mistake?

Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1538048
@enj enj mentioned this pull request Mar 14, 2018
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@soltysh soltysh soltysh left review comments

@juanvallejo juanvallejo Awaiting requested review from juanvallejo

@knobunc knobunc Awaiting requested review from knobunc

Assignees

@enj enj

@simo5 simo5

Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files.
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
8 participants
@deads2k @simo5 @enj @liggitt @openshift-ci-robot @openshift-bot @openshift-merge-robot @soltysh