Types of access managed by the DuploCloud Platform
DuploCloud manages users' access to the cloud provider. This is achieved by creating a session in the cloud provider whose permissions are the same as the Tenant's IAM role.
In the case of AWS, such sessions are transient and do not require a username to be created in the cloud provider. When logged into the AWS console, the username appears as <tenant_name>/<email_address>. Note that this user has the same access as the Tenant in the IAM role. The same principle is used for CLI access. See the JIT section for more details.
In the case of GCP, the session is generated and has the same permissions as the Tenant's IAM role. The username itself does exist in GCP because it is a GSuite user, but the permissions that are generated and associated are Just-In-Time for the duration of the session.
In the case of Azure, each user is added to the user access list for the resource group that the Tenant is part of. The validity of this session is tied to the validity of the user login. The session's access is not transient and is permanently attached to the resource group for as long as the user has access to the tenant.
All user activity in the direct cloud provider is tracked in the cloud provider audit trail like cloud trail.
SSH access to Hosts in the DuploCloud Platform
Just-in-time access to the VM shell is supported for AWS and GCP. Behind the scenes, the platform orchestrates AWS SSM and GCP console access features to achieve this. Users connect to the shell by navigating to Cloud Services -> Hosts -> VM_Name -> Actions -> Connect SSH, as shown below. In the case of Azure, use the Azure console to access the VM, and using the left navigational menu, choose the Connect -> Azure Portal option.
Authentication methods supported by the DuploCloud Platform
You can SSO to the DuploCloud platform via Google, Microsoft, or Okta. We do not manage usernames and passwords within DuploCloud. A user's identity on the platform is their email address.
The Tenant is the basis of all access management. Users only need to be granted access to the Tenant, and from there, when they login to the DuploCloud platform, they are given access to the individual resources within that tenant on a need-basis, as described in the next section.
Beyond Tenant-level access, there are three additional user types:
ReadOnly
Administrator
Security Auditor, who only views the monitoring aspects of security.
Users can also create groups in Microsoft AD or Okta that can be mapped to Tenants in DuploCloud. All administration can be performed from AD or Okta.
Just-In-Time access to cloud resources in the DuploCloud Portal
Access management pertains to giving users limited, need-based, and just-in-time access to the underlying cloud resources like access to cloud provider console/tokens, Virtual Machine shell, kubectl, etc.
Configure Permission Sets in DuploCloud for granular access control
Permission Sets in DuploCloud provide fine-grained access control for users. They define which APIs/resource types a user can access within specific Tenants. Permission Sets can be assigned directly to users or bundled into Permission Groups for easier management.
A Permission Set is a collection of allow or deny policies applied to users. These policies define which APIs, resource types, and HTTP methods a user can access within specific Tenants. Permission Sets are evaluated by priority, with lower numbers overriding higher numbers. Permission Sets can be system-wide, assigned directly to users, or assigned to user groups.
A Permission Group is a bundle of users assigned one or more Permission Sets. Groups simplify administration by giving multiple users the same access rules and are ideal for managing permissions by team or role. Users inherit all permissions from the Permission Sets assigned to the group. Users can belong to multiple groups, and all permissions from their assigned groups are combined.
In the DuploCloud Portal, navigate to Administrator → Permissions.
Select the Sets tab.
Click Add. The Add Permission Set pane displays.
Complete the following fields:
Name
Enter a meaningful name for the Permission Set (e.g., deny-k8s-job).
Scope
Select the appropriate scope for the Permission Set (e.g., User or System Wide). Note: Choosing System Wide creates a Permission Set that applies to all users. This can be used for default allow-all permissions or to enforce explicit deny rules across the platform.
Priority
Enter a numeric value; lower numbers take higher precedence. (Tip: start with higher numbers like 50 for flexibility.)
Applicable Tenants
Select the applicable Tenants or choose All Tenants.
Allow or Deny Policy
Click Add Allow Policy or Add Deny Policy and complete the following fields:
Resource Type RegEx: Enter the resource type (e.g., k8s/job).
API Name RegEx: Enter a regex matching the API (e.g., .*k8s/job.*).
Method: Choose GET, POST, PUT, DELETE, or ALL.
Click Save to create the Permission Set.
After creating a Permission Set, assign specific users to it:
In the DuploCloud Portal, navigate to Administrator → Permissions.
Select the Sets tab.
Select the Permission Set from the NAME column. The Permission Set details page displays.
Select the Users tab.
Select the users to whom the Permission Set should apply.
Click Save.
User Groups allow you to assign multiple users the same set of permissions at once.
Navigate to Administrator → Permissions.
Select the Groups tab.
Click Add. The Add Permission Group pane displays.
Complete the fields:
Name
Enter a descriptive name for the Permission Group.
Users
Select one or more users to include in the group.
Permissions
Click Add under Permissions. The Add Permissions pane displays:
Select one or more Permission Sets to assign to the group.
Click Add to confirm the selection.
Click Add to create the Permission Group.
Users inherit all permissions from the assigned Permission Sets.
Users can belong to multiple groups; all permissions are combined.
It is possible for a user to be assigned multiple Permission Sets that contain contradictory rules. DuploCloud resolves conflicts using the following logic:
Priority Evaluation: Permission Sets are evaluated in ascending priority (lower numbers first).
First Match Wins: The first matching policy (allow or deny) determines access.
Default Deny: If no policy matches, access is denied by default (400 error).
Example:
Permission Set A (priority 5) denies GetSecretData
Permission Set B (priority 10) allows GetSecretData
Result: access is denied because Permission Set A has higher precedence.
Best Practices:
Assign careful priority numbers to Permission Sets to ensure intended behavior.
Use Permission Groups to simplify management, but check for overlapping sets with conflicting rules.
Log in as a user assigned to a Permission Set or a User Group.
Attempt actions governed by the assigned Permission Set(s).
Verify that access is granted or denied according to the rules.
Access Kubernetes constructs directly in the DuploCloud platform
The DuploCloud Platform enables access to every Tenant's namespace to which the user has access. You can temporarily access config maps via SSO authentication tokubeconfig. Permissions are scoped to the Kubernetes namespace.
For administrators, Kubernetes access via SSO is available from the Administrator -> Infrastructure -> K8S. See these detailed instructions.
Access to the container shell in the DuploCloud Portal
Users can access the container's shell. No keys are required; you can access it securely with one- click. The platform manages access for Kubernetes, ECS, or Docker Native-based deployments.
Access the container by selecting the Host/VM and clicking the Containers tab. Then, click the options menu next to the selected container ( ) and select Container Shell.
