-
Notifications
You must be signed in to change notification settings - Fork 28
Conversation
By using the `escalate` verb on clusterroles, we allow the Operator to have the ability to create any clusterrole. This prevents us from needing to grant it `cluster-admin`. Additionally, by having the Operator create an aggregated clusterrole for itself (aggregating all clusteroles created by Knative Eventing), we pick up any permissions that the upstream dictate as necessary by any component. Any roles that are not created by upstream, but which are bound as part of install are added with the `bind` verb. Overall, this should keep the Operator roughly operating only on Knative Eventing resources (or things which can be operated on by upstream).
b3b5524
to
37601fd
Compare
This should begin to pass once we regen the eventing YAML |
/retest |
{"level":"info","ts":"2020-03-06T23:29:47.135Z","logger":"eventing_operator.knativeeventing-controller.event-broadcaster","caller":"record/event.go:274","msg":"Event(v1.ObjectReference{Kind:"KnativeEventing", Namespace:"operator-tests", Name:"knative-eventing", UID:"cdb13e43-2533-4246-8050-3886920854ef", APIVersion:"operator.knative.dev/v1alpha1", ResourceVersion:"2475", FieldPath:""}): type: 'Warning' reason: 'InternalError' clusterroles.rbac.authorization.k8s.io "source-observer" not found","commit":"025ff25","knative.dev/controller":"knativeeventing-controller"} |
This allows us to take advantage of the permissions granted to cluster admins when performing cleanup. If the approach in knative#109 is approved, this will become necessary. Additionally, it makes sense to remove roles as the final step to allow human Operators to modify any resources they may have permissions on as a result of the Knative installation (that is, we should not remove any access until we are 'almost done' cleaning up).
This allows us to take advantage of the permissions granted to cluster admins when performing cleanup. If the approach in knative#109 is approved, this will become necessary. Additionally, it makes sense to remove roles as the final step to allow human Operators to modify any resources they may have permissions on as a result of the Knative installation (that is, we should not remove any access until we are 'almost done' cleaning up).
* Delete (Cluster)Role(Bindings) as a final cleanup step. This allows us to take advantage of the permissions granted to cluster admins when performing cleanup. If the approach in #109 is approved, this will become necessary. Additionally, it makes sense to remove roles as the final step to allow human Operators to modify any resources they may have permissions on as a result of the Knative installation (that is, we should not remove any access until we are 'almost done' cleaning up). * Remove redundant All(), fix conditional.
/assign @n3wscott |
Whoops, big mistake in the existing role. This needs an update and retest. |
/unassign @n3wscott |
New issue seems to be the use of the operator-tests namespace, iirc this was dropped for kserving. |
This order, Roles -> RoleBindings -> The Rest, prevents the operand from needing to structure their manifest such that this ordering exists, while allowing the Operator to use the bootstrapping mechanism described in knative#109 to 'escalate' itself into management of the Knative Eventing installation without a *** clusterrole.
Bah humbug, let's see what the problem is. |
/retest |
msg: "Event(v1.ObjectReference{Kind:"KnativeEventing", Namespace:"operator-tests", Name:"knative-eventing", UID:"41eff4b4-2aee-478d-99dc-9baf59462f1d", APIVersion:"operator.knative.dev/v1alpha1", ResourceVersion:"2200", FieldPath:""}): type: 'Warning' reason: 'InternalError' serviceaccounts "eventing-controller" is forbidden: User "system:serviceaccount:default:knative-eventing-operator" cannot get resource "serviceaccounts" in API group "" in the namespace "operator-tests"" Aha, right, the namespace thing, maybe I can test it out on a different namespace |
Very odd that both tests pass locally. I'm going to tilt at that windmill for a bit. |
Oh :) That was a silly reason. |
/assign @n3wscott Assuming my last minute diff-tweaking didn't break this, this should be ready to review :) The role defined in role.yaml is a strict subset of that in serving-operator, where in that repo If the Operator repos and/or controllers are to merge, this dramatically simplifies the collapse of |
And knative-eventing namespace to knativeeventings namespaces.
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Cynocracy, n3wscott 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 |
Fixes #106
#150 is a base of this, you can solely review the YAML here
(and not the reconciler change) though you're welcome to review
that as well.
Proposed Changes
By using the
escalate
verb on clusterroles, we allow the Operatorto have the ability to create any clusterrole. This prevents us from
needing to grant it
cluster-admin
.Additionally, by having the Operator create an aggregated clusterrole
for itself (aggregating all clusteroles created by Knative Eventing),
we pick up any permissions that the upstream dictate as necessary
by any component.
Any roles that are not created by upstream, but which are bound as
part of install are added with the
bind
verb to allow the Operatorto bind them without necessarily having the permissions they grant.
Some other permissions are needed to support controller infra
and are explicitly included, as well as some specific to the Operator
itself. An attempt at grouping these by sections is included, though
may be slightly out of sync (in particular: Controller infra / Specific
to this Operator may overlap).
Overall, this should keep the Operator roughly operating only on
Knative Eventing resources (or things which can be operated
on by upstream).
Release Note