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.

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 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.

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.

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 .

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.