Orchestrator Security Considerations: Section 2: Account Management

One of the practical problems that we come up against in Orchestrator is how effectively manage accounts. It seems easy to just run everything under one ‘super user’ account that has access to everything, i.e. provision an Orchestrator AD account, give it Domain Admin privileges and administrative privileges to all of our databases and management systems but for some reason our security team doesn’t seem to agree with this model so, the question becomes, what is an acceptable model? We decided that we wanted to mirror our web development environment and best practices as closely as possible which means developing Development, QA and Production Tiers of workflows across our Development, QA and Production Orchestrator environment Silos (the actual Orchestrator environments).

Workflow Tiers

Development Workflows

These are workflows that target test environments. This is the first category of workflow we create when tackling a new automation project. All connections run under ‘Orchestrator Account 100’ which only has access to pre-defined test environments. The easiest way to understand this is with a practical example, let’s an automated server build process. The first iteration of the automation project we undertook was built in a test domain, using our test instance of SCCM and on our test VMWare Virtual Center. All of these connections were made with ‘Orchestrator Account 100’ which only has access to those environments. This limits us from making a ‘whoops’ inside of a production environment during our first implementation.

QA Workflows

Once we have tested and become comfortable with a development version of a workflow we will take on a request to create a QA version of that automation. This version DOES NOT replace the development version, rather it is based on a copy of the development version. We take the development workflow, export it modify the connections and re-import it into the environment as a separate workflow. The workflow is then gone through and updated to work against a limited set of pre-defined QA resources with ‘Orchestrator Account 200’. In our practical example started above this means that we create a new version of the Virtual Server build inside of our Production AD Forest, our QA SCCM Environment and our QA VMWare Virtual Center environment, all connection with ‘Orchestrator Account 200’ (this account has limited permissions inside of our Production AD Forest to limit its potential for destruction).

Production Workflows

Once we have tested and become comfortable with a QA version of a workflow we will take on a request to create a Production version of that automation. This version DOES NOT replace the QA version, rather it is based on a copy of the QA version. We take the QA workflow, export it modify the connections and re-import it into the environment as a separate workflow. The workflow is then gone through and updated to work against Production resources with ‘Orchestrator Account 300’. In our practical example started above this means that we create a new version of the Virtual Server build inside of our production AD Forest, our Production SCCM Environment and our Production VMWare Virtual Center environment, all connection with ‘Orchestrator Account 300’ this account has permissions across all of our production environments and is only used after workflows have been vetted in their QA form.

Environment Silos

Development Silo

  • Where the ‘new version’ of the workflow tier (Dev/QA/Prod) is initially developed
  • A given workflow tier will go through many iterations here during a development sprint
  • Test cases defined during requirements gathering phase and passed using developer testing tools
  • All updates / changes to a workflow tier initiate here, no changes are made in the QA or Production Silos

QA Silo

  • Where the ‘new version’ of the workflow tier (Dev/QA/Prod) will be staged for requester testing
  • Requesting group tests as the intended end user
  • Load Testing is run on the workflow to judge its impact on the Production environment when promoted
  • All requested changes will be made in the Development Silo then re-promoted to QA for further testing by requesting group

Production Silo

  • Where the ‘Production’ version of an project lives
  • Current ‘gold’ standard of a given workflow tier (Dev/QA/Prod)
  • Only updated once the requesting team is satisfied with the QA version

 

Account Ramifications

  • Each ‘Tier’ of workflow will run under a different security context.
  • That ‘Tier’ of workflow will run under the given security context across all Orchestrator environment Silos

 

Advertisements
Tagged with: , ,
Posted in General Information, Infrastructure
2 comments on “Orchestrator Security Considerations: Section 2: Account Management
  1. Curtiss says:

    so for your production workflow/production silo, do you just make the orchestrator runbook service account a local administrator on all your production servers? how do you do this? via group policy? what about on domain controllers, aka DNS servers, where there is no local administrator group? has MS put out a best practices document for orchestrator permissions?

  2. Eli Howard says:

    I enjoy what you guys aare usually up too. This kind of clever work and
    reporting! Keep up the terrific works guys I’ve incorporated you guys to
    my own blogroll.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: