[FEATURE REQUEST] Add limited AppRole orchestration mode(s)

[lkubb]

Is your feature request related to a problem? Please describe.
Currently, when orchestrating AppRoles, the Salt master needs wide privileges. This allows a dynamic setup without a lot of overhead and integrates well into Salt.

However, in the tradeoff between automation and security, this puts more emphasis on the automation side. It could be beneficial to allow running with more limited privileges on demand.

Describe the solution you'd like

There are several privileges that could be made optional.

0: AppRole/Entity creation
Disable AppRole/Entity creation. An external tool like Terraform could be used for management instead, which ties the AppRole/Entity creation to node deployment. This would always be the case for the following switches.

1: RoleID access
Don't allow the master to read the RoleID of an AppRole. In this scenario, the external tool would read the RoleID and embed it into the node on creation. The master only issues SecretIDs on demand. This is how AppRoles are supposed to operate, but the Salt master having complete access to minions is a special case.

Notes:

• This breaks the vault external pillar and all SSH wrapper modules.
• A compromised Salt master would still be able to assign arbitrary policies and extract the RoleID from the running minion.
• Effectively, this just increases the complexity of data extraction.

2: Token policy management
Don't allow the master to manage AppRole-associated token policies, use the external tool instead.

Notes:

• This breaks dynamic policy assignments (policy templating).
• A Salt master would not be able to escalate its privileges beyond the set of policies all of its minions hold, effectively reducing the blast radius of a compromise. This is similar to what Token Roles enable for token issuance, with different tradeoffs. (See the last bullet point in the security notes)

3: Entity metadata management
Don't allow the master to manage Entity metadata.

This has similar semantics as described in (2), but is usually much less severe if left enabled (depending on the templated ACL policies that make use of the entity metadata ofc).

Describe alternatives you've considered
Disabling credential orchestration and configuring the minions manually via config_location.

Additional context
This is a rough draft of possible future functionality, discussion is encouraged. It's something that has been on my mind for a while, but it's not implemented in any form and I'm not working on it at the moment.