Inside of Orchestrator there are two types of roles, for simplicity sake we will call them developer and analyst. The developer role is controlled by adding people or groups to the OrchestratorsUserGroup group on your environments management server, access to the analyst role is configured by modifying permission on Runbook Folders. The Analyst role will be further discussed in section 3 but the distinction between the two is relatively simple, one (Developer) is for creating new Runbooks and making modifications to existing Runbooks, the other (Analyst) is for executing Runbooks through the web console or web service.
What is the issue with the developer role?
The crux of the problem with one ‘Developer’ role is that we cannot segregate access inside of an Orchestrator environment. Once you have access to a development environment you have access to all connections made under Global Configurations. This means that if I make a connection to Active Directory with a Domain Admin account for some automation task, anyone who has access to that Orchestrator Development environment could use that connection to Active Directory. This means that my Active Directory administration team cannot live in the same environment as other groups who do not have access to that level of account (Domain Admin).
Okay, so how do we work around this?
We have decided that the easiest way to work around this is architecturally. We have tiered out our Orchestrator environment into development pods, a single central QA environment and a mirrored Production environment. Each development team is provisioned their own development pod and sets up their own connections to external systems, those connections are then persisted our central environments. This ends up giving us the following architecture
Central Environment Considerations
This does mean that your central environments will have access to all environments that your child Runbook PODs have access to, this may or may not be acceptable for your deployment. In our environment we have policies surrounding our central QA and Production environments which prevent us from changing any Runbooks in either tier, all changes must come from a development environment in the form of a Runbook export.