OCPBUGS#52452: Grant ce permissions#110805
Conversation
ca9fbfb to
43a8421
Compare
|
@trgeiger PTAL I know there are some rough edges here. And for that, I apologize. Please leave as detailed comments as you can for the writer who will be following up on this ticket during my leave. cc: @mwerner2113 @oceanc80 @joelanford @kalexand-rh @nmuller66 |
|
@michaelryanpeter: all tests passed! Full PR test history. Your PR dashboard. 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-sigs/prow repository. I understand the commands that are listed here. |
|
Looking at the preview, in Granting CE permissions, I can see that the content is out of order. I think that the core of the required content is here, minus a "template" or set of default permissions. A bit of reshuffling is in order. |
| In {olmv0-first}, a single service account with cluster administrator privileges manages all Operators. | ||
|
|
||
| {olmv1} is designed to be more secure than {olmv0} by default. {olmv1} manages a cluster extension by using the service account specified in an extension's custom resource (CR). Cluster administrators can create a service account for each cluster extension. As a result, administrators can follow the principle of least privilege and assign only the role-based access controls (RBAC) to install and manage that extension. | ||
| {olmv1} manages cluster extensions by using the service account specified in the custom resource (CR) that defines the extension. Cluster administrators can create a service account for each cluster extension and assign the minimum role-based access controls (RBAC) required to install and manage that extension. |
There was a problem hiding this comment.
I wonder if "specified in the custom resource (CR) that defines the extension" is a bit confusing since we would typically refer to the place where you would define the SA for the cluster extension as the ClusterExtension's manifest or something. Maybe just putting a parenthetical at the end specifying that the CR in this case is ClusterExtension?
|
Additionally, I think since we specify in the opening sections that there's two approaches to deriving the RBAC and that one of them is "Manually scope RBAC" and then we have a major section later on the page titled "Manual cluster role scoping," we should probably have a hyperlink between these two or organize the page in a way that it makes sense to link them. |
|
The This is because your PR targets the If the update in your PR does NOT apply to version 5.0 onward, please re-target this PR to go directly into the appropriate |
I am about to go on leave, and I expect that another writer will take over this PR. I am uncertain about the content of the second commit and we might need an example of a "cluster role template" for another module.
My apologies for the rough state of the PR and AI slop I did not catch.
Please reach out to @mwerner2113 with questions or concerns.
Version(s): 4.18+
Issue: https://redhat.atlassian.net/browse/OCPBUGS-52452
Link to docs preview:
QE review: