From Physical Isolation to Logical Isolation

VPC-based Network Isolation

Figure 1 VPC-based network isolation

VPC is a cornerstone of tenant security. It provides a completely isolated network space for customers to deploy services on the cloud. A VPC is a secure network environment by default. Customers can build necessary network channels as required while ensuring security. VPCs communicate with external networks using the following connection methods:

• Internet access: Security measures such as Anti-DDoS Service (AAD), Web Application Firewall (WAF), and Cloud Firewall (CFW) are used to ensure the security of Internet access through Elastic IP addresses (EIPs).
• Hybrid cloud access: CFW and other methods are used to safeguard on-premises equipment room access through Direct Connect and Virtual Private Network (VPN).
• Cloud service access: VPC Endpoint (VPCEP) is used to access cloud services, and VPCEP policies are used to ensure secure access to cloud services.

VPC provides two basic network security access control capabilities: security group and network access control list (ACL). Both are Layer 4 stateful network security capabilities.

• Security group: configures access policies for inbound and outbound traffic over ENIs or ENI sets.
• Network ACL: configures access policies in the inbound and outbound directions for subnets, including the source and destination IP addresses, ports, and protocols, and associates with specified subnets.

VPC also supports network encryption. For a VPC with encryption enabled, the traffic between compute resources and gateways within the VPC is transmitted using encrypted packets. This ensures that all customer traffic is encrypted and cannot be cracked or listened to by cloud providers.

Figure 2 VPC network encryption

The QingTian hardware system enables VPC to provide network isolation, traffic encryption, and network access control based on security groups and network ACLs. The VPC management plane delivers the entries required by the network subsystem to QingTian Cards. QingTian hardware virtualizes ENIs through VF passthrough and connects to compute resources (such as ECSs, BMSs, and CCI pods) for intra-VPC forwarding.

• Security access control module: To control access through security groups and network ACLs, QingTian hardware identifies the ENI and subnet of each packet based on its associated VF, and then finds the corresponding security groups and network ACL security policies. After policy evaluation, QingTian hardware determines whether to forward the packet and generates session entries required by the stateful firewall to ensure that subsequent packets are correctly forwarded.
• VPC routing module: To enforce VPC-isolated packet forwarding, QingTian hardware searches for the routing entries dedicated to the customer's VPC based on the ENIs and subnets of the packets, encapsulates the packets in a VXLAN tunnel, and sends the packets. The destination QingTian hardware locates the VPC-specific routing tables of the packets based on the encapsulated information in the VXLAN and forwards the packets. Throughout the entire forwarding process, forwarding is isolated by searching for VPC-specific routing tables.
• VPC encryption module: To encrypt VPC traffic, QingTian hardware finds the encryption key dedicated to the VPC based on the packets' VPC attributes, and adds an encrypted packet header to the VXLAN tunnel to encrypt all packets, including the MAC address, IP address, and other forwarding information, as well as additional information about the VPC of the packets in the VXLAN tunnel. The encryption key is shared among compute nodes in a given VPC. The destination QingTian hardware can find the key based on the key ID, decrypt the key, and continue the subsequent forwarding process.

Multi-Tenant Resource Isolation for Cloud Service Access

In a tenant VPC, customer applications deployed on Enclaves (or VMs) may depend on API calls of multiple cloud services, such as OBS or KMS. However, these cloud services are deployed outside the tenant VPC. To allow customer applications to access cloud service APIs, Huawei Cloud uses VPC endpoints to break the VPC network isolation perimeter. VPC endpoints use one-way access and endpoint policies to control the attack surface on the access path.

Figure 3 Multi-tenant resource isolation

By default, cloud service APIs support multi-tenant resource access control and isolation based on the IAM access control system. Huawei Cloud IAM provides tenants with centralized identity and access control management as well as unified access control policy language, and offers consistent access control decisions for all cloud service APIs. IAM PDP supports multiple types of access control policies, including VPCEP policies, IAM identity policies, and cloud service resource policies. IAM access control policies support a variety of condition attributes. Currently, more than 50 global condition attributes and more than 500 cloud service condition attributes are supported. These condition attributes include identity attributes, session attributes, runtime environment attributes, network attributes, API context attributes, and target resource attributes. Tenants can flexibly combine condition attributes to customize IAM policies to meet security control or compliance requirements.

The QingTian system ensures correctness and integrity of the runtime environment attributes and network attributes required by IAM PDP. The QingTian system registers metadata with IAM through IAM Context Provider. The metadata includes the context verification public key and context assertion schema. QingTian injects context assertions with digital signatures into API access links. IAM PDP verifies the integrity of the context and executes the access control policy evaluation logic related to API requests based on the trusted context assertions.

Multi-Tenant Resource Isolation Across Cloud Services

If your account subscribes to multiple cloud services, cross-service resource access may be involved. Cross-service resource access may cause the confused deputy problem. Inappropriate design of service access isolation may result in unauthorized access by other tenants.

Huawei Cloud solves the confused deputy problem at the protocol design level. By default, the subscribed service principal is restricted within the account domain of the tenant. Different cloud services in the same account domain are completely isolated. Access cross cloud services requires explicit authorization from the tenant.

Huawei Cloud IAM provides AssumeAgency and Impersonation security protocols to authorize access across cloud services in a given account domain.

• Protocol 1: AssumeAgency
  Figure 4 AssumeAgency
  

  AssumeAgency is typically used when cloud service jobs need to be authorized to access downstream cloud service resources after users have gone offline. An administrator creates an IAM agency, specifies Service-X as the trusted principal in the trust policy, grants appropriate permissions to the agency, and passes the agency to Service-X.

  By default, Service-X in the IAM agency trust policy indicates Service-X in your account domain (or organization domain). Service-X subscribed by other accounts is not trusted, and Service-X in other account domains does not have permission to assume the agency. By introducing the account domain (or organization domain), we can solve the confused deputy problem of cross-cloud service access at the protocol level and provide default multi-tenant security isolation.

• Protocol 2: Impersonation
  Figure 5 Impersonation
  

  Impersonation is typically used when the cloud service request processing logic needs to access downstream cloud service resources when users are online, such as the flow of "User -> OBS -> KMS". Administrators do not need to grant additional permissions to OBS. This protocol allows OBS to impersonate the identity and permissions of the requester to access the downstream cloud service KMS.

  For example, a user attempts to call the OBS GetObject API to get the object data encrypted using the tenant KMS key. However, the OBS service principal was not authorized to access the tenant KMS key. In this case, OBS needs to impersonate the caller to call the KMS API.

  Specifically, OBS provides API RequestProof of the caller to apply for a forwarding access token from STS, and then uses the token to construct a KMS API access request. API RequestProof contains the API name, API signature, and expiration time. It ensures security of impersonation. STS checks whether the API has an associated impersonation license and whether the API signature is valid, and then determines whether to issue the corresponding forwarding access token. The permissions of the forwarding access token obtained by OBS are the intersection of the permissions granted to the caller and the scope-down session policy associated with the API. The scope-down session policy associated with an API is designed based on the principle of least privilege. It can be registered in the production environment only after being reviewed by the cloud security team, IAM team, and cloud service team.