Share This:

Problem statement customers have brought to us: User in a role has broad access to the environment, a high level of privilege, and maybe not an ideal level of training to be “Safe” operating with impunity in the environment.  As an automation solution owner, I want to help our users be safer, and enable them to follow good practice within the automation solution.  How do I start, and how can TSSA help me?

 

This topic is sometimes called "separation of duties", and also uses the principle of least privilege: what is the least amount of access I need to successfully do my job?

 

Two common approaches here:

 

  1. Approved Content Promotion / Separation of Duties: Validating jobs in a non-prod environment before deploying to production: A number of customers build out content promotion workflows using RBAC in TSSA to support this process.  It’s straightforward to explain ways to solve this using TSSA, and it is common to use RBAC to enable a content promotion / validation workflow.
    1. While objects under the covers in TSSA are versioned, the previous versions of objects aren’t directly exposed to the user.  What customers are doing is baking a version number into those job names, and putting them into hardened repositories where many users can consume, but only specific, approved users can edit or promote content into those repositories / folders.  So, for the average user, or the mid-level engineer: “You can do anything you want, as long as it’s an approved automation”.
    2. Implementing separation of duties basically consists of having a “dev” type role that can create content, and typically has a small sandbox of servers for testing automations: packages and scripts, a promotion role that does some testing and then sends approved automations onward to a production role that doesn’t do content creation, but executes pre-approved automations or changes.
  2. Some customers have used an externalized workflow that would explicitly export jobs from TSSA, check them into source control, and re-import them under a different role.  This is more complicated, and requires custom scripting that the customer would own, and has some limitations, but there are customers that do this, including across a sort of “air gap” between a non-prod and prod environment.  The source control component isn't strictly necessary here, but this is one way to integrate source control not only for content, but also for the job definitions themselves.

 

I’m always happy to have a conversation about how other customers have solved these problems and how to address yours, feel free to reach out to me or Bill Robinson