.svg?alt=media&token=0f6df7c7-5b98-4a62-98b8-a54e38a8329e){kind=logo}
Isolation and Firewall
An overview of the security constructs ensuring isolation in the DuploCloud environment
Last updated
An overview of the security constructs ensuring isolation in the DuploCloud environment
Last updated
© DuploCloud, Inc. All rights reserved. DuploCloud trademarks used herein are registered trademarks of DuploCloud and affiliates
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.
A Tenant is similar to a Kubernetes namespace with an extended cloud provider scope. Most cloud resources directly consumed by applications reside within a Tenant, such as databases, queues, storage, VMs, etc. Some resources are shared, including but not limited to VPC, VMs, Encryption Keys, SSL certs, etc. You can also create resources in one Tenant and allow other Tenants to consume those via inter-tenant access policies.
