Access Management

Access Management within StackGuardian Orchestrator allows administrators to control user access levels within the organization. The interface provides options to assign roles to users or groups, define custom roles, and manage login methods.

Role-Based Access Control (RBAC)

RBAC is a method of regulating access to resources based on the roles of individual users within an enterprise. In StackGuardian, RBAC allows for granular control over the actions that users and groups can perform, which is crucial for large organizations with complex access control requirements.

Use Case

Consider a scenario in a large organization where different teams need different levels of access to workflows, Connectors, and policies. With StackGuardian RBAC, you can create a role named DevOps that has permissions to Create, Update, and Delete workflows, but only Read access to secrets.

Add Users and Assign Roles

Navigate to Orchestrator > Organization settings tab on the left.

To add a new user to your organization, follow these steps:

1. In the "Add User or Group" section, enter the email ID or AD group. For example, newuser@example.com.
2. Assign a Role from the dropdown that reflects the user's function within the organization. Please note that, by default, you can assign a maximum of 5 roles per user within an organization. To increase this limit, please open a support ticket.
3. Select the Login Method, which can be a direct login or Single Sign-On (SSO), depending on your setup.
4. Click on the Add button to finalize the addition of the new user.

After adding, the user will appear in the list above, where you can modify their access or remove them as needed.

Pre Defined Roles

Role	Description	Permissions & Descriptions
ADMIN (Administrator)	Full access to all settings and features across the platform.	All permissions including management and configuration of all aspects.
READ_ONLY (Read Only)	View access to all organizational settings and configurations, without the ability to modify anything.	Only view access to settings, no modifications allowed.
DEV (Developer)	Focused on development activities.	- Create, view, and manage organization settings. - Generate and view reports. - Manage secrets and policies. - View and manage workflows within workflow groups. - Manage Connector groups and Connectors. - Execute, view, and manage workflows and their runs. - Handle stack configurations and operations.
SEC (Security Specialist)	Specialized in security with access tailored to manage security settings and sensitive data.	- Create and manage organization reports. - Manage secrets and policies. - View workflows and their outputs. - Authenticate and manage Connector settings. - Limited management of workflow configurations. - Oversee security aspects of stack operations.
OPS (Operations Specialist)	Geared towards operations management.	- Manage organization settings and secrets. - Create, update, and delete policies. - Full management of workflow groups, workflows, and their runs. - Manage Connector groups and Connectors. - Handle operational aspects of workflow configurations. - Supervise and operate stacks and stack runs.
Custom Roles	Customizable roles to fit specific organizational needs, with permissions assigned as needed.	Custom permissions based on organizational requirements.

note

You can create custom roles to fit unique requirements of your organization in the "Define Role" tab.

Custom Roles

In the StackGuardian Orchestrator, defining roles is crucial for managing and customizing access levels across your organization. The Define Roles tab allows for the creation of roles that cater to specific responsibilities and access requirements within your organization. Navigate inside the role created for further configurations.

Permissions Overview

Tailor permissions to meet the specific needs of roles, team members, and access levels for efficient access control. Below is an outline of other permission categories:

• Workflows & Stacks Permissions: Manage user interactions with Workflow Groups, Workflows, and Stacks. This could range from viewing lists to creating, updating, or deleting workflows and stacks.

• Connectors Permissions: Control access to Connectors, Connector Groups.

• Policy & Secrets Permissions: Manage permissions related to Templates, enabling users to access, update, or create new templates.

• Template Library Permissions: Manage permissions related to Templates, enabling users to access, update, or create new templates.

• Roles & Others Permissions: Provide or restrict access to additional administrative functions like Role management, API Token generation, viewing Audit logs, and generating Organization Reports.

info

For example, an Admin Role can be set up by selecting All permissions under each category. This provides unrestricted access, suitable for administrative users who require full control over the platform.

Assign Permissions

To set up and assign roles for a DevOps team member, follow the steps below to assign permissions effectively:

Step 1: Add Permissions

1. In the Admin Portal, access the newly established DevOps role.
2. Navigate to Workflows & Stacks Permissions.
3. Click "Add Permission (Preview)" and proceed with the following steps:

Use the dropdown menu to view and assign permissions. You can either assign all permissions for admin access or selectively choose specific permissions. Start with the foundational permissions such as Get Workflow.

Permission	Description
Get Workflow	View the list of workflows within workflow groups.
Create Workflow	Create new workflows within any workflow group.
Update Workflow	Edit existing workflows in any workflow group.
Delete Workflow	Remove workflows from any workflow group.
List Workflow Artifacts	Access a list of artifacts related to workflows.
Get Workflow Outputs	View outputs generated by workflows.
Get Workflow Run	Access details of workflow execution runs.
Run Workflow	Execute workflows within a group.
Cancel Workflow Run	Cancel running workflows if needed.
Get Workflow Run Logs	Retrieve logs for workflow execution runs.
Resume Workflow Run	Resume paused or stopped workflow executions.
Get Workflow Runfact	Fetch run-related facts for workflows.
Get Stack	View details of stacks in the organization.
Create Stack	Add new stacks for managing infrastructure.
Delete Stack	Remove stacks as required.
Run Stack	Execute stacks for deployment or configuration.
Get Stack Run	Access details about stack runs.
Get Stack Outputs	View outputs generated by stack runs.
Get Stack Workflow	Access workflows associated with a stack.
Update Stack Workflow	Edit workflows tied to specific stacks.
Delete Stack Workflow	Remove workflows from stacks.
Get Stack Workflow Outputs	View outputs from stack-related workflows.
List Stack Workflow Artifacts	List artifacts related to stack workflows.
Get Stack Workflow Run	View details of stack workflow runs.
Get Stack Workflow Runfact	Fetch facts for stack workflow runs.
Resume Stack Workflow Run	Resume paused stack workflow executions.
Get Stack Workflow Run Logs	Retrieve logs for stack workflow execution runs.

Step 2: Assign Paths

1. After assigning permissions, move to the Assigned Paths to add nested resources.
2. Use the dropdown to select workflow groups, stacks and workflows created under your organization.
3. Once done, click "Add (Preview)".

How Regex Works in Path Assignments

StackGuardian supports full match regex patterns when assigning paths under permissions. This allows flexible control over nested resources like workflow groups, stacks, and individual workflows.

note

We perform full string matching, which means the pattern must match the entire path, not just a part of it. You don't need to use ^ (start anchor) and $ (end anchor) in your regex patterns as they are automatically applied.

Syntax Guide:

• Use regex to dynamically match multiple path options.
• .* matches any character(s), allowing flexibility across different path names.
• Avoid using overly generic patterns to prevent unintended access.

Example Pattern:

For workflow group permissions, you can use regex patterns to control access and naming restrictions. The behavior differs between Create Workflow Group and Create Nested Workflow Group permissions.

info

Important: For Get permissions (like viewing workflows), the regex processing works differently. When you specify a path like a/b/c, it automatically grants access to that path AND all its parent paths (a, a/b, and a/b/c) because you need to traverse through parent groups to access the target.

Pattern 1: Create root workflow groups with name restrictions (Create Workflow Group and other create resources permissions that work on the root level (Policies, Connector, etc))

• Regex pattern: team-a-.*
• What it does: Limits creation of root-level workflow groups to names matching the pattern (no hierarchy involved)
• ✅ Will allow creating:
  • team-a-frontend (matches the team-a- prefix)
  • team-a-backend-api (matches the team-a- prefix)
  • team-a-123 (matches the team-a- prefix)
• ❌ Won't allow creating:
  • team-b-frontend (doesn't match team-a- prefix)
  • frontend-team-a (team-a not at the start)
  • other-project (completely different pattern)

Pattern 2: Create nested workflow groups in parent group only (Create Nested Workflow Group permission)

• Regex pattern: parent_wfgrp/name-pattern.*
• What it does: Allows creating workflow groups directly under parent_wfgrp with names matching the pattern
• ✅ Will allow creating:
  • parent_wfgrp/name-pattern-dev (matches the name pattern)
  • parent_wfgrp/name-pattern123 (matches the name pattern)
• ❌ Won't allow creating:
  • parent_wfgrp/other-name (doesn't match name pattern)
  • parent_wfgrp/child/name-pattern-test (nested too deep)

Pattern 3: Create nested workflow groups in any sub-group (Create Nested Workflow Group permission)

• Regex pattern: parent_wfgrp/.*/name-pattern.*
• What it does: Allows creating workflow groups in any sub-group under parent_wfgrp with names matching the pattern
• ✅ Will allow creating:
  • parent_wfgrp/team1/name-pattern-frontend (in sub-group, matches pattern)
  • parent_wfgrp/team2/name-pattern-backend (in different sub-group, matches pattern)
• ❌ Won't allow creating:
  • parent_wfgrp/team1/other-pattern (doesn't match name pattern)
  • parent_wfgrp/name-pattern-direct (directly under parent, not in sub-group)

Pattern 4: Create in specific nested path with name restrictions (Create Nested Workflow Group permission)

• Regex pattern: company/team/project/service-.*
• What it does: Allows creating workflow groups only under the specific path with service-prefixed names
• ✅ Will allow creating:
  • company/team/project/service-api (exact path, matches service- prefix)
  • company/team/project/service-database (exact path, matches service- prefix)
• ❌ Won't allow creating:
  • company/team/project/component-ui (doesn't match service- prefix)
  • company/other-team/project/service-api (wrong path)

Pattern 5: Access to specific nested path (Get Workflow Group permission)

• Regex pattern: company/team/project
• What it does: For Get permissions, grants access to the specified path AND all parent paths
• ✅ Will match:
  • company (parent path - needed for navigation)
  • company/team (parent path - needed for navigation)
  • company/team/project (the target path)
• ❌ Won't match:
  • company/team/project/feature (child paths)
  • company/other-team (sibling paths)

info

You can test your regex patterns live using regex101.com.

Delete Permission

To remove assigned permissions, follow these steps:

1. Navigate to the permission list.
2. Use Options > Delete to remove permissions individually or collectively.

Assigning a Custom Role

After creating a custom role, it becomes available under the "Assign role" tab. To assign this role:

1. Navigate to the Assign Role tab.
2. Select the User/Group name to whom you want to assign the permissions.
3. From the Assign Role dropdown, search for and select the name of the custom role created (e.g., _custom_role_).