Orchestrator Security Considerations Introduction

We just completed an internal review about how to handle security in Orchestrator and a lot of good conversation was had around the topic that I think will be applicable to the larger Orchestrator community. There are quite a few portions to the discussion so I will be breaking it down into a series of blog posts addressing multiple topics, hopefully people find them useful when developing your own security model!

Section 1: Global Configurations

This section will focus on one of the largest security restrictions the product has; namely the fact that you cannot scope access to any global configurations or variables to sub groups of Orchestrator developers, once you have developer access to a development environment you can access it all! I will talk about how we have decided to architect around this problem and what the environment ramifications are of this

Section 2: Account Management

This section will focus on how we handle levels of account privileges (ie accounts with access to Development, QA and Production resources) and how we map these permissions to different levels of Runbooks (Development / QA / Production)

Advertisements
Tagged with: , ,
Posted in General Information, Infrastructure

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: