Sorry for the slow response.

Thanks Dmitriy for the outline of the read-only access.

Additional "admin" access probably wasn't a good way to describe what I was
referring to. Below is a description of an approach that I think could be a
very powerful target state and help with many of the challenges we’ve been
facing. I can only assume it is a bit more than you were looking for in the
context of introducing the UAA into BOSH. It obviously requires changes to
BOSH beyond integration of the UAA.

I think the proposed roles (and corresponding scopes) of full admin, which
can be thought of as “root” for the Director, and full read-only make sense
as is. The other roles I would propose would require providing an option to
externalize credentials and other sensitive information from deployment
manifests.

- Secrets Manager

Manifests generally contain a lot of sensitive information and basically
give you full access to a deployment. In regulated and security sensitive
environments, identity and secrets management can be a dedicated
function/role. It would be beneficial to provide an option to use a syntax
in manifests to reference external “secrets” so that the deployment manifest
need not contain any sensitive information. The secrets would be sourced
into the manifest when BOSH requires them. Either BOSH itself would provide
the secrets management or, optimally, a pluggable mechanism could be
provided to retrieve them from a dedicated secrets management solution (e.g.
something like Hashicorp Vault).

The secrets management capability, if native to the platform, could also be
leveraged by release authors so that sensitive information does not need to
be written to the filesystem of the BOSH VMs but rather dynamically fetched
when a job starts or when needed.

For those not interested in externalizing secrets from manifests, the
existing approach would continue to work.

- Deployer

A deployer is the role that is permitted to introduce change into the
environment. It is similar to the
'bosh.<DIRECTOR-UUID>.deployments-tag.<TAG>.admin’ already proposed scope.
They can modify specific deployments that exist and new deployments. To
adhere to least privilege, if a deployment externalizes secrets as outlined
above, the deployer preferably would not be able to access those
credentials. Deployers should not need nor require access to the deployed
system (e.g. bosh ssh).

- Deployment Support

For lack of a better description, I refer to the last role as deployment
support. The support role has the ability to access the running systems or
access an operations that would be used to support the environment. Beyond
the capabilities of the read-only role, this would include operations such
as:
* ssh/scp
* cloudcheck
* logs
* recreate/start/stop/restart job

A concrete use case for this role follow. In many environments, persistent
access to production systems is not permitted. Access to production systems
should only be allowed when there is some type of incident ticket or change
ticket registered. When a ticket is registered, an external system could
dynamically assign a “bosh.<director-uuid>.deployments-tag.<tag>.support”
scope to the appropriate user(s) in the UAA (or a backing store of the UAA
such as LDAP). When the ticket is closed that scope would be revoked
(assumes token expiry is set to a sufficiently short period since I don’t
believe there is token invalidation in the UAA).

Hopefully this makes some sense. I can provide some additional use cases
around the roles if it helps.



--
View this message in context: http://cf-bosh.70367.x6.nabble.com/cf-bosh-Resuming-UAA-work-tp75p207.html
Sent from the CF BOSH mailing list archive at Nabble.com.