Workspaces & RBAC

Scale across multiple organizations with isolated environments, granular team permissions and centralized audit logs.

What it is

Enterprise-grade multi-tenancy. Create distinct workspaces for different teams (e.g., "Frontend", "Data Science") and enforce strict Role-Based Access Control (RBAC) to ensure people only touch what they own.

When to use it

Separating "Prod" access (SRE only) from "Dev" access (Engineers).
Managing external contractors who need limited scope to specific resources.
Auditing "Who changed what and when" for compliance certification.

Use Cases

Real-world scenarios

Least Privilege for Developers

The Problem

Every engineer had `AdministratorAccess` to AWS because crafting fine-grained IAM policies was too difficult.

The Solution

Created a "Developer" role in DeployN. They can "View" Prod but "Edit" Dev. They can trigger deployments but cannot destroy loose resources.

Result: Drastically reduced blast radius of human error without blocking developer velocity.

Contractor Safe Zones

The Problem

External consultants needed access to optimize the database but shouldn't see S3 buckets containing user data.

The Solution

Created a "Consultant" workspace scoped only to RDS resources and tagged with `project:optimization`.

Result: Safely collaborated with 3rd parties without sharing root credentials or broad access keys.

Audit Logs for SOC2

The Problem

The auditor asked for a list of everyone who touched the payment gateway infrastructure in the last 90 days.

The Solution

Exported the DeployN Audit Log, filtering by `resource:payment-gateway` and `action:update`.

Result: Passed the audit section in minutes with a CSV export provided directly to the auditor.

How It Works

Step 1:Create Organization

The top-level container for your company billing and policy.

Step 2:Define Roles

Use built-in roles (Admin, Editor, Viewer) or create custom policies.

Step 3:Assign Groups

Map your Identity Provider (Okta, AzureAD) groups to DeployN roles.

Step 4:Set Scope

Limit access by Environment (Dev/Prod), Region, or Resource Tags.

Measurable Outcomes

A+

Security Score

Improved IAM posture by removing long-lived static credentials.

Instant

Onboarding

New hires land in correct workspaces automatically via SSO JIT provisioning.

-90%

Audit Prep

Time spent gathering evidence for compliance audits.

Technical Implementation

SSO Mapping

You can map your Okta "Engineering" group directly to the "Developer" role to automate onboarding.

RBAC Policy Definition

HCL

resource "deployn_team" "developers" {
  name        = "Frontend Developers"
  permissions = ["read", "plan", "apply"]
  
  workspace_ids = [
    deployn_workspace.dev_env.id,
    deployn_workspace.staging_env.id
  ]
}

ARCHITECTURE FLOW

This diagram represents the logical flow of data within the Workspaces & RBAC module, demonstrating how it integrates with your existing stack.

Common Questions

Do you support SAML/SSO?

Yes. Okta, Google Workspace, Azure AD and OneLogin are supported on the Enterprise plan.

Can I view the audit logs via API?

Yes. You can stream audit logs to Splunk, Datadog, or S3 for long-term retention.

Can I restrict access by IP?

Yes. You can whitelist IP ranges that are allowed to access specific workspaces.

How granular are the permissions?

Down to the resource type. You can allow "Restart EC2" but deny "Terminate EC2".

Does this override AWS IAM?

No. DeployN assumes an IAM role. Our RBAC sits on top of that to control *access to the deployment engine*.

Ready to implement Workspaces & RBAC?

Join the waitlist to get early access and start building your visual infrastructure today.

Get Started Now