BUILD-284: Relocate shared resources api into openshift/api repository#979
BUILD-284: Relocate shared resources api into openshift/api repository#979openshift-merge-robot merged 1 commit intoopenshift:masterfrom coreydaley:jira_build_284_integrate_shared_resources_operator
Conversation
|
@coreydaley: This pull request references Bugzilla bug 1986557, which is valid. The bug has been moved to the POST state. The bug has been updated to refer to the pull request using the external bug tracker. 3 validation(s) were run on this bug
Requesting review from QA contact: DetailsIn response to this:
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. |
|
/assign @adambkaplan @bparees |
|
why is this a bug? looks like part of a feature. |
|
/hold since this is going in as a no-FF feature, it will need qe/docs/px acks before it can merge. but that should not hold up getting an api-review approval. |
|
/hold Maintaining the hold due to openshift/csi-driver-shared-resource#39. I've put a few renames in flight to give a coherent branding experience:
The API group and directory structure should be updated here (no longer use |
|
/cc @jitendar-singh @rolfedh @RickJWagner For qe, docs, and PX acks on this. |
|
@adambkaplan I have updated this pull request to correlate with the renaming of the projected resource driver. Can you ptal and see if this falls in line with your updates? |
adambkaplan
left a comment
There was a problem hiding this comment.
I don't think we need the display name. Only other item is to add explicit owners, then it looks good to me.
|
@deads2k @gabemontero @adambkaplan @jsafrane @soltysh @mfojtik |
|
/hold cancel |
gabemontero
left a comment
There was a problem hiding this comment.
LGTM but I'll defer to others to apply the appropriate labels
adambkaplan
left a comment
There was a problem hiding this comment.
Looks like there is the one CRD yaml file that was missed, otherwise I think we're in good shape!
| // `oc create role shared-resource-my-share --verb=use --resource=sharedconfigmaps.sharedresource.openshift.io --resource-name=my-share` | ||
| // `oc create rolebinding shared-resource-my-share --role=shared-resource-my-share --serviceaccount=my-namespace:default` | ||
| // | ||
| // Administrators can create separate Roles and RoleBindings for their users to be able the list and/or view the |
There was a problem hiding this comment.
What do you see the default as? Autthenticated list/watch of SharedConfigMaps and SharedSecrets?
There was a problem hiding this comment.
Are you asking if any authenticated user of the cluster will be able to list/watch the shared resources? If not, could you please elaborate on your question?
There was a problem hiding this comment.
Are you asking if any authenticated user of the cluster will be able to list/watch the shared resources?
yes. What is the default policy?
There was a problem hiding this comment.
I'll step in for this one (after discussing this with @coreydaley on slack today, as well has prior discussion I've had with @adambkaplan )
So yeah @coreydaley can augment the godoc here @deads2k, providing a compact summary of the following:
- we envisioned some aggregation to the default roles .... for this one, I believe we are talking the
viewrole - with that, users can get (that is missing in this current version), list, and watch
SharedConfigMapandSharedSecret - so they can know which actual
ConfigMaporSecretis being shared via a get on theSharedConfigMaporSharedSecret - but they cannot of course see inside the
ConfigMaporSecretunless they have sufficient permissions to those objects in the namespaces they reside - minor sidebar -
oc describe ...does a get under the covers
Any issues or things we missed there @deads2k ?
thanks
There was a problem hiding this comment.
In putting ^^ together @deads2k I am working off of https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles and hence believe we could aggregate get/list/watch perms for our 2 new cluster scoped CRDs here, assuming we all agree that is "safe", and I am in fact interpreting that doc correctly.
There was a problem hiding this comment.
@deads2k Updated with default permissions information. ptal
|
after the reference and default policy, I think it is ready to merge. |
|
/lgtm |
|
/lgtm cancel |
Operator Co-authored-by: Adam Kaplan <adam.kaplan@redhat.com> Co-authored-by: Gabe Montero <gmontero@redhat.com>
|
@deads2k Updated per your request, ptal. |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: coreydaley, deads2k, gabemontero, rolfedh, soltysh 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 |
https://issues.redhat.com/browse/BUILD-284