How do we configure DuploCloud RBAC and just-in-time access for production, including custom roles (Advanced/Scale)?

For most teams running production workloads on DuploCloud, the goal is the same: give developers enough access to move fast, without ever putting sensitive environments at risk. Role‑based access control (RBAC) and just‑in‑time (JIT) access are the foundations of that model—especially on Advanced and Scale plans, where you’ll typically have multiple teams, environments, and compliance requirements to juggle.

This guide walks through how to design and configure DuploCloud RBAC and JIT access for production, including how to approach custom roles, guardrails, and practical workflows.

Core concepts: tenants, roles, and access scopes

Before configuring RBAC and JIT access, it helps to align on how DuploCloud models access:

Tenants
- Logical isolation boundaries for applications/environments (e.g., dev, staging, prod, or per‑customer tenants).
- Tie into DuploCloud’s tenant model, which enforces strong segmentation and is central to logical access control for SOC 2, HIPAA, PCI‑DSS, ISO 27001, and GDPR.
Roles
- Collections of permissions that define what a user or group can do in DuploCloud.
- Out of the box, you’ll have system roles (e.g., admin, developer, read‑only) and, on Advanced/Scale, you can define custom roles tuned to your organization’s needs.
Identity providers (IdPs)
- DuploCloud integrates with IDPs such as Gsuite and O365 to manage authentication and user lifecycle.
- Groups from the IdP can be mapped to roles and tenants in DuploCloud to centralize access control.
Least privilege and segmentation
- Instance profiles and managed identities limit access to underlying AWS/Azure resources.
- Network segmentation and tenant boundaries ensure users and workloads are scoped to only what they need.

Step 1: Design your access model for production

Start with a simple, consistent model and evolve as needed. For most Advanced/Scale customers, a good baseline is:

1. Separate tenants for each environment

Use distinct tenants for:

appname-dev
appname-staging
appname-prod (or multiple prod tenants for different business units/customers)

This lets you:

Keep production workloads strictly isolated.
Apply different RBAC and JIT rules to prod vs. non‑prod.
Enforce segmented network and cloud resource access per tenant.

2. Define clear persona‑based roles

Think in terms of “what this person needs to do” rather than job titles. Common personas:

Platform / DevOps engineer
- Needs broad infrastructure control, but often only elevated in production during incidents or changes.
Application developer
- Needs to deploy services, view logs/metrics, and manage app‑level resources, but not platform‑wide settings.
SRE / On‑call engineer
- Needs elevated troubleshooting access during incidents, especially in production.
Security / compliance
- Needs visibility into configurations, logs, and audit trails, but not necessarily the ability to modify.

You’ll map these personas to roles (standard or custom) and then scope those roles to tenants.

Step 2: Connect DuploCloud to your identity provider

To keep production access secure and auditable, use your enterprise IdP as the source of truth:

Enable SSO with Gsuite or O365 (or other supported IdPs).
Create IdP groups aligned with your personas and environments, for example:
- duplo-dev-app-team
- duplo-prod-app-team-jit
- duplo-platform-admins
- duplo-security-readonly
Map IdP groups to DuploCloud roles and tenants, so:
- Membership in duplo-dev-app-team → Developer role on dev/stage tenants.
- Membership in duplo-prod-app-team-jit → Base read access to prod, with JIT elevation when needed.
- Membership changes in IdP automatically reflect in DuploCloud.

Using the IdP means:

Joiners/movers/leavers are handled centrally.
You can apply MFA and conditional access policies at the IdP level.
Audit logs from both DuploCloud and the IdP support SOC 2 and other compliance audits.

Step 3: Configure baseline RBAC for non‑production

Non‑production environments are where teams iterate quickly, so you typically relax restrictions slightly while still enforcing best practices.

Recommended baseline for dev/stage

Developers
- Role: Developer (or a custom role that:
  - Can deploy services, update configs, manage CI/CD‑triggered releases.
  - Can view logs, metrics, and basic infrastructure resources within the tenant.
  - Cannot change global platform configuration, central networking, or shared security policies.
- Scope: dev and staging tenants.
Ops / Platform
- Role: Admin or PlatformAdmin custom role.
- Scope: All tenants, but with internal policy that production use still goes through JIT.

Give developers self‑service access in dev/stage with guardrails: DuploCloud enforces security and compliance best practices automatically, so even non‑prod infrastructure is built with the same baseline controls.

Step 4: Lock down production with stricter RBAC

Production needs tighter control and stronger separation.

Recommended baseline for production access

Developers
- Default: ReadOnly role on production tenants.
- They can:
  - View logs, metrics, deployments, and configs.
  - Self‑serve investigation without causing changes.
- Any modification (deployments, config changes, infra changes) goes through:
  - CI/CD pipelines with approvals, or
  - JIT elevation (see the next section).
On‑call / SRE
- Default: Read access similar to developers.
- JIT: Can elevate to a higher privilege role (e.g., ProdOperator) during incidents.
Platform / DevOps
- Default: Restricted or read‑only access by default to reduce blast radius.
- JIT: Elevation to ProdAdmin only for planned changes or incident response.
Security / compliance
- Role: SecurityReadOnly custom role with:
  - View access across all tenants.
  - Access to audit logs, configuration, and compliance dashboards.
- No ability to deploy, modify infrastructure, or change network settings.

This model ensures that:

No one has permanent “god mode” in production.
Most actions happen via audited CI/CD pipelines.
Manual access is tightly controlled and time‑bound.

Step 5: Implement just‑in‑time (JIT) access for production

JIT access means users only get elevated privileges when they actually need them—and only for a defined period.

Design your JIT workflow

JIT typically includes:

Request
- User requests elevation to a specific role (e.g., ProdOperator) in a specific tenant (appname-prod).
- Include:
  - Reason for elevation (incident ID, change ticket).
  - Expected duration (e.g., 30–120 minutes).
Approval
- Approver is usually a:
  - Team lead.
  - On‑call lead.
  - Platform or security owner.
- Approvals can be integrated with:
  - ChatOps (Slack/Teams).
  - ITSM tools (Jira, ServiceNow).
  - Internal access management tools.
Elevation
- On approval, DuploCloud grants the user the elevated role in the specified tenant.
- The permission is:
  - Time‑bound (auto‑expires).
  - Logged for auditing.
Expiration and review
- Access automatically returns to baseline role.
- Security/compliance teams periodically review:
  - Who requested elevation.
  - Frequency of requests.
  - Actions performed during elevated sessions.

Practical patterns for JIT in DuploCloud

Role pairs for each persona
- Example:
  - ProdDeveloperReadOnly (baseline)
  - ProdDeveloperJIT (elevated)
- Users are always in the read‑only group; they are temporarily added/assigned to the JIT role via automated workflows.
Tenant‑specific JIT
- For critical tenants (e.g., customer‑facing prod), use shorter JIT durations and stronger approval (2 approvers, or mandatory security sign‑off).
- For internal production tenants, you might allow slightly longer JIT windows.
Audit trail
- Require that each JIT request references a ticket or incident.
- Correlate DuploCloud audit logs with your ticketing system during compliance audits.

This approach aligns with DuploCloud’s focus on strong logical access controls and helps demonstrate SOC 2 controls in action.

Step 6: Create and manage custom roles (Advanced/Scale)

On Advanced and Scale editions, you can define custom DuploCloud roles to match your organizational structure and compliance profile.

Custom role design principles

Least privilege
- Start from a minimal set of permissions and add only what’s necessary.
Separation of duties
- Split responsibilities:
  - CI/CD and deployments vs. platform configuration.
  - Security monitoring vs. infrastructure changes.
Environment awareness
- Create distinct roles for prod vs. non‑prod where behavior should differ.

Example custom role patterns

ProdOperator
- Intended for: On‑call engineers handling incidents in production.
- Capabilities:
  - Restart services.
  - Trigger rollbacks.
  - Update environment variables/feature flags.
  - View all observability data.
- Restrictions:
  - Cannot modify core networking, security policies, or tenant‑wide settings.
PlatformAdmin
- Intended for: Platform/DevOps teams.
- Capabilities:
  - Configure tenants, shared networking, and cluster‑level resources.
  - Manage CI/CD integrations.
- Restrictions:
  - May not have direct access to application secrets or data.
SecurityReadOnly / Auditor
- Intended for: Security and compliance stakeholders.
- Capabilities:
  - View all tenants, configurations, and audit logs.
  - Export evidence for SOC 2, HIPAA, PCI‑DSS, ISO 27001, GDPR.
- Restrictions:
  - No write permissions.
AppTeamProdJIT
- Intended for: Specific application squad in production.
- Capabilities:
  - Deploy their own services and manage configurations in their prod tenant.
- Restrictions:
  - No cross‑tenant access, no platform‑level changes.
- Assigned only via JIT workflows.

Governance for custom roles

Maintain a central RBAC policy document listing:
- All roles.
- Their permissions.
- Who can request or approve them.
Review role definitions at least quarterly as part of your compliance and security posture review.
Keep custom role configuration under infrastructure‑as‑code where possible (stored in version control for audibility and change tracking).

Step 7: Integrate RBAC and JIT with CI/CD and automation

To keep security embedded in every deployment and workflow:

Use CI/CD as the primary change path
- Most production changes should flow through automated pipelines, not manual console changes.
- DuploCloud supports CI/CD automation and observability integrations, enabling:
  - Repeatable provisioning.
  - Automated rollbacks.
  - Policy‑compliant deployments.
Limit manual console usage in production
- Require JIT elevation for:
  - Manual hotfixes.
  - Emergency configuration changes.
- Enforce that such changes are later codified in CI/CD pipelines to avoid configuration drift.
Event‑driven automation
- Use DuploCloud’s event‑driven automation to create:
  - Alerts on JIT access requests and approvals.
  - Automated logs export for security review.
  - Tickets for post‑incident review when high‑risk JIT roles are used.

Step 8: Continuous monitoring and compliance

With RBAC and JIT in place, ensure you maintain continuous visibility and compliance:

Continuous compliance monitoring
- Use DuploCloud’s compliance capabilities to:
  - Monitor configuration drift.
  - Ensure that RBAC policies align with SOC 2, HIPAA, PCI‑DSS, ISO 27001, and GDPR requirements.
- Leverage automatic guardrails that DuploCloud enforces for all deployments.
Audit and reporting
- Regularly export and review:
  - Audit logs of user actions.
  - JIT access requests and approvals.
  - Changes to roles and tenant assignments.
- Provide this evidence during SOC 2 and other audits to demonstrate strong logical access controls.
Periodic access reviews
- Quarterly or monthly:
  - Validate that role assignments are still appropriate.
  - Remove access for users who no longer need it.
  - Adjust custom roles if permissions have drifted from least‑privilege.

Putting it all together: a sample production access pattern

Here’s how a mature setup might look in practice:

Developers
- Dev/stage: Full developer role in their own tenants.
- Prod: Read‑only by default, plus JIT elevation to AppTeamProdJIT for specific incidents or changes.
Platform / Ops
- Dev/stage: PlatformAdmin with broad control.
- Prod: Baseline limited role; JIT to ProdAdmin for planned changes or high‑severity incidents.
SRE / On‑call
- Prod: Read‑only plus JIT to ProdOperator during incidents.
Security / Compliance
- All tenants: SecurityReadOnly for complete visibility, no write.
All elevation events
- Requested through a standardized workflow (chat/ITSM).
- Time‑bound and auto‑reverted.
- Logged and periodically reviewed.

With this model, you get:

Fast, self‑service workflows for developers.
Strong segmentation and least‑privilege access in production.
Built‑in support for SOC 2 and other frameworks through DuploCloud’s tenant model, IdP integration, and compliance automation.
A clear, auditable story for how production access is requested, granted, used, and revoked.

If you share your current team structure and environments, we can outline a concrete DuploCloud RBAC and JIT configuration tailored to your setup, including specific example roles and mappings.