To reach a private network that hosts the various cloud resources, DuploCloud integrates with OpenVPN in a point-to-site topology. This is explained further here.

The DuploCloud Infrastructure construct maps to a VPC in AWS and GCP. In Azure, it maps to a VNET. Setting up the network is the first step, followed by the creation of DuploCloud Tenants, which are children of the DuploCloud infrastructure, as shown in the policy model. Kubernetes clusters are tied to the network and are part of this setup. For detailed guidance on infrastructure and network setup, refer to the individual cloud provider sections AWS, Azure, and GCP in their respective guides in this documentation set.

Subnets within a network infrastructure are tied to availability zones. A single application's multiple replicas are typically spread across multiple subnets. Subnets thus are not an isolation construct by default. However, you can deploy workloads in specific subnets when they launch the virtual machines. In the case of Azure, subnets also have special considerations, for example, different types of Azure PaaS services require their special subnets.

All resources in the cloud provider that allow resource provisioning to have a network interface associated are placed in private subnets. This is a straightforward configuration in AWS and GCP. In Azure, the platform deals with the more complicated workflows around creating private endpoints and hosted zones.

WAF provides an HTTP-level firewall with advanced mechanisms for bot protection, geofencing, rate limiting, and so forth. The WAF should be created and curated directly in the cloud provider interface and a reference to the WAF added to the platform using the Administrator -> Plans menu.

Subsequently, when creating the load balancer endpoints, this is attached.

Each Tenant has its Security Group and within the Tenant the Security Group allows full access between resources. Various cloud-managed services like AWS RDS, Opensearch, MSK, Azure SQL, etc are created and placed in their respective Tenant's security groups so that any computing resource in that Tenant can reach them.

An administrator can allow inter-Tenant traffic by explicitly opening them using the Add Tenant Security pane, available by navigating to Administrator -> Tenants -> Security.

In Azure, network security is implemented at the virtual network level and all traffic within the VNET is allowed. This behavior can be overridden by placing a low-priority deny rule for all VNET traffic. Azure ASGs allow intra-Tenant traffic. So if the user desires they can treat the Tenant as a security boundary with the above-suggested approach. Navigate to Administrator -> Infrastructure -> Security to open the Add Infrastructure Security pane.

Access to PaaS services by cloud providers is not network policy-based but based on the provider's IAM framework. For example, AWS uses IAM policies, Azure uses managed identities and GCP uses service accounts. Similarly, in a Kubernetes cluster, service accounts are used.

DuploCloud Tenant is an IAM boundary. Any PaaS resource within a Tenant is automatically accessed by the compute workload using IAM. For example:

• In AWS, each Tenant is an IAM role and computing resource, as VMs, Lambda functions, EMR, Airflow Jobs, etc are given the IAM role which in turn is configured to have access to all PAAs services in that Tenant like S3 buckets, DynamoDB tables, secrets manager, SSM parameter, SQS queues etc.

• In Azure, each Tenant is a managed identity and computing resource, as VMs, Lambda functions, etc are attached to this managed identity which in turn is configured to have access to all PaaS services in that Tenant like Azure storage, Keyvault, etc.

• In GCP, each Tenant is a service account and computing resource, as VMs, functions, etc are attached to this service account which in turn is configured to have access to all PaaS services in that Tenant like cloud storage, Pub/Sub, etc.

Isolation of the environment is the most basic principle in any infrastructure security implementation. Cloud providers allow many constructs to implement this isolation to varying degrees. For example, you can isolate two workloads in completely different cloud accounts, different VPCs within the same account, or different "security groups" within the same VPC. Then there are other constructs like IAM (AWS roles, Azure managed Identity, GCP service accounts) or Kubernetes namespaces, and so forth. But how do we bring together dozens of these security constructs and map them to an application-centric isolation model?

DuploCloud gathers these constructs together in a single application-centric model, in the figure below, which is described in more detail here. To summarize, there have three layers of isolation:

• Account Level: This offers the deepest grade of separation. As it is heavyweight, it also incurs maximum overhead in terms of maintenance and cost as almost no construct can be reused across two environments.

• VPC Level (a.k.a DuploCloud Infrastructure): Within the same account, environments are segregated by virtual networks (VPC/ VNET).

• Security group and IAM (a.k.a DuploCloud Tenant): Within the same account and same VPC, we can isolate by having separate security groups, IAM roles (Managed Identity in AWS, Service accounts in GCP), encryption keys, etc. A DuploCloud Tenant is similar to an environment. Two Tenants can reside in the same VPC, in different VPCs, or within different VPCs in various accounts.

The cloud provider account is the greatest barrier, providing security and isolation.

• Azure Subscription: One DuploCloud portal can manage multiple Azure subscriptions. To add a subscription, click Administrator -> CloudCredentials, as shown in the figure below. You can use a managed identity or a service principle with keys

• AWS Account: In AWS, you need one DuploCloud VM per AWS account, because in AWS, the account is the fundamental IAM construct. The AWS organizations and SCP are very lightweight and were more recently added in the AWS product lifespan, unlike Azure which uses Active Directory as the fundamental IAM construct. Originally DuploCloud used to manage multiple AWS accounts, but this support was removed after consistent feedback from customers and security experts. The best practice evolved to one VM agent per account, federated in a single pane, allowing you to switch accounts as needed, using the Switch Account list box.

• Google Project: Multiple GCP projects can be added and managed by the same DuploCloud installation. To add a project, click Administrator -> CloudCredentials, as shown in the figure below.