Hide Forgot
Created attachment 1225349 [details] Example Roles Customer asked to Document Document URL: https://docs.openshift.com/enterprise/3.2/admin_guide/manage_authorization_policy.html#viewing-cluster-policy Section Number and Name: Example 1, Default Cluster Roles Describe the issue: Customer has asked for a Functional Description of what each role provides to any User or Service Account given a role. Suggestions for improvement: Describe the what capability the role provides from either a Developer, Operational, or System perspective and how/why combinations of Roles may be required for specific types of capabilities (e.g. ability to deploy Images from one project in another). Additional information: See attachment for example set of roles that the customer is currently tasked with documenting for an internal review.
Hey Greg - Thanks for this and the attachment. I have a few questions: 1. Did the customer create this document? Are they able to help us validate the finished descriptions? 2. What is the priority on this? This looks to be a big ask, so I want to figure out how vital is this. 3. Is this more than one customer could be asking for help with? Thanks! Adding in Ali Heslin (content strategist).
Hi Vikram - Yes, the customer created the document, and I believe would open to collaborating with us. This request only came from one customer, and is a medium high, priority, in that their internal security team is more closely assessing the customers current OpenShift deployment. I would be happy to also collaborate with you between now and the end of the year, as I have some spare cycles that I could use to contribute based on you and your teams guidance.
Here's some additional feedback from the customer, stripped of anything customer specific: We can help review the description of the groups provided, but for the most part we’d need on rely on Redhat to identify what they are for, I don’t know that we could provide any input on ‘correctness’, probably just more on ‘understandability’ of the description provided. If this helps, for the role based access document I’ll be creating from this, there are two columns they’ve requested. One is “Role Description (Rights Associated with role)” which is pretty much what the role is used for (in English, not the details of the rules granted to it). The second is “Business Justification (include the specific team/job function that should be allowed to have this role and the operational need to view/update the data in that function which aligns with Minimum Necessary access.). Hopefully this will provide some additional background in the type of information we’d be looking for in the documentation on each role. 2. On priority. I expect that we have a few weeks. We’re working on another document right now that is a somewhat higher level around user, service account and group management in OSE from our access management system. I’ll be starting some work on the role worksheet next week, probably trying to review first which roles we’d consider to have “Security Admin” capabilities based on their ability to create/manage groups, users, service accounts or roles. I’ll be reviewing the permissions in the worksheet to see if I can get a feel for which allow that. I’ll probably run it by you once I’ve looked through it. 3. I can’t really speak to other customers, but I can only imagine that there would be others that want to understand what the roles are for, so when they’re looking to grant some sort of permissions they have an idea of what all the existing roles are intended for. Otherwise it could make it challenging to pinpoint which role provides the least amount of privelge required to accomplish something, instead of just adding identities or groups to the role with the most permissions because they can’t figure out what other one might fit.
Hey Greg - thanks for the updates. If you have a few spare cycles available, I suggest that you give us a head start by creating a knowledgebase article for this. A member of the docs team can review this doc and work with you to make sure it adheres to the right guidelines and update it if necessary. Let me know if you need help with creating the KBase article.
Hi Vikram - This recently bubbled up again with the customer. I apologize for not responding sooner to your (good) idea of creating a knowledge base article. I would be happy to do that, but I need a supporting list of technical details on what capabilities that each of the User and Cluster roles provides. What I'm looking for is something like "enables ability to acces projects acrosss all namepsaces", "provides the ability to change the cluster SCC", or "provides the ability to create Persistent Volumes for the Cluster" You will probably have to go back to the engineering to get all that info, but then I could draft something that might identify how to use/grant those permissions to support the potential Development, Operational, Admin, and possible Business Analyst types of roles that would access OpenShift. Let me know if you agree with this approach, and understand what I'm asking for. I'm happy to have a quick call with you if that would be helpful.
Thanks Greg. Let me check in with Ali and Eric and get back to you next week.
Eric - what do you think of this idea?
(In reply to Vikram Goyal from comment #7) > Eric - what do you think of this idea? @Greg, please link the support case to the BZ so we can track how many customers are asking for this, and so we can align the BZ severity to the severity of the case (or collective of cases). In addition to this I wonder how related https://bugzilla.redhat.com/show_bug.cgi?id=1377411 is to this request? (In reply to Greg Hoelzer from comment #3) > “Role Description (Rights Associated with role)” > which is pretty much what the role is used for (in English, not the details > of the rules granted to it). The second is “Business Justification (include > the specific team/job function that should be allowed to have this role and > the operational need to view/update the data in that function which aligns > with Minimum Necessary access.). Hopefully this will provide some > additional background in the type of information we’d be looking for in the > documentation on each role. Based on this feedback I think they are asking for the first tab of the document! It makes since to have these descriptionss for each of these roles (we should have a doc that is updated that explains the use for each role). However, aligning this with, what each role (does - the verbs/actions), this undertaking is hard to manage with docs, as its dynamic (or fluid) based on what engineering needs the roles to do (as the product changes). Because of this I feel you likely want to provide a script or tool (we may already have RFE's for this) that provides this information on the role. Having this scripted allows the output to be saved, and audited with each update to the product. Example Script: > # oc get clusterrole -o jsonpath='{range .items[*]}{"The role "}{.metadata.name}{" can\n "}{range .rules[*]}{.verbs[*]}{" on the following resources:\n "}{.resources[*]}{"\n "}{end}{end}{"\n"}' (In reply to Greg Hoelzer from comment #5) > What I'm looking for is something like "enables ability to acces > projects acrosss all namepsaces", "provides the ability to change the > cluster SCC", or "provides the ability to create Persistent Volumes for the > Cluster" > > You will probably have to go back to the engineering to get all that info. I agree, this needs to come from the Dev teams that are creating / generating these roles with in the product.