IAM permissions for Automate users of InfraServer views

[kalroy]

User Story

As an Automate admin user I should be able to define the permissions of views of the Infra Server.

Cookbooks

• [x] #5748
• [x] #5749

Roles

• [x] #5750
• [x] #5765
• [x] #5766
• [x] #5767
• [x] #5768
• [x] #5769
• [x] #5770
• [x] #5771

Environment

• [x] IAM permission to view Environment - https://github.com/chef/automate/issues/5879
• [x] #5886
• [x] #5887
• [x] #5889
• [x] #5890
• [x] #5891
• [x] #5892
• [x] #5893

Databag

• [x] #5935
• [x] #5936
• [x] #5937
• [x] #5938
• [x] #5959
• [x] #5960
• [x] #5961
• [x] #5962

Client

• [x] #5973
• [x] #5974
• [x] #5990
• [x] #5991
• [x] #5992
• [x] #5993
• [x] #5994
• [x] #5995

Nodes

• [x] #5986
• [x] #5987
• [x] #5988
• [x] #5989

PolicyFile

• [x] #5963
• [x] #5964

PolicyGroup

• [x] #6053
• [x] #6054

Organization

• [x] #5823
• [x] #5824

InfraServer

• [x] #5820
• [x] #5821
• [ ] #5822

Chef Managed Policies

• [x] #6318
• [x] #6319
• [x] #6330
• [x] #6331

Projects

• [ ] #5779

Definition of Done

Demo Script / Repro Steps

[btm]

@kalroy I said something in the meeting, but I'll say again what you started here is great. :partying_face:

The permissions matrix feels pretty big and hard for us to make sure it is implemented and works as we desired. Have you thought about how to document that? For the ticket itself, for the tests, and/or for the final docs?

I thought about Administrator/Editors/Viewers versus Project Owner/Editor/Viewer some when I was drafting #5742, and it was clear we need to write down what this is holistically somewhere, but also I wasn't 100% sure on the appropriate terminology of policies/roles and which we would apply to the API and ultimately to the UI or UX decisions we would make based on that (e.g. don't display a tab, or leave it there but have it gray with a mouse-over that explains they don't have access or what).

Some of those decisions, like in #5742, we might need to make as we go. Or we could play it safe and require 'Administrator' for some new functionality, like the users tab, and then do a better job at identifying/discussing the personas that apply to those IAM policies in this epic.

I was looking at the IAM docs today and noticed this:

https://docs.chef.io/automate/iam_v2_overview/#assigning-resources-to-projects

Two categories of resources exist for project assignment:

Ingested client run and compliance nodes Teams, API Tokens, Policies, and Roles created in Automate

Which doesn't mention Infra Server organizations. Which is a "doc bug" but, mostly, it's a reminder for me that this epic is a big body of work to do well.

[kalroy]

@btm Thank you for your inputs. I agree this work is absolutely necessary and important considering the dependency we have on the roles here. These roles would impact:

• the ability of the API
• the ability to view the UI

This needs to be done right and start early. As per my understanding, the behaviour of the UI may change as we will have our discussions but based on some the discussions we have with a couple of customers and CAs it seems to me that they like the idea of not allowing to even view everything they are not supposed to view (specifically data bags).

Regarding the process to get these done properly across testing, implementation and docs, this is how we are approaching:

• Every new action needs to be applied to the relevant APIs
• Every new action needs to be applied in the UI to make it behave accordingly
• Every new action needs to be updated in an internal document under dev-docs folder
• Every new action needs to have an API integration test using cypress

The idea of the docs is to make sure that we have all the relevant information internally as well as to present to the docs-team to update the public docs when we are ready to expose this work to the customers.

Would like to hear your thoughts on this approach.