Security design
The following are security design considerations for connecting cloud services to on-premises environments by using the Private Path service.
Access control
Access policies control access to the Private Path service. Every time a new Virtual Private Endpoint tries to access to a Private Path service, a new connection request appears in the Private Path service page in the IBM Cloud console.
The default policy is set to Review all requests, which means all the connection requests require explicit approval. Review the following policies:
- Review all requests - All incoming requests are sent to the service provider for review and triage. the reviewer permits or denies the connection request. The service provider is notified of all connection requests that do not have account policies that are associated with the account IDs.
- Permit all requests - This setting automatically approves connection requests for all account IDs that do not have account policies. This policy is the most expedient for both the service provider and consumer. However, accepting "all" requests also presents a security risk, especially if the Private Path service's cloud resource name (CRN) is widely distributed.
- Deny all requests - All incoming requests to the service are rejected. If you want to allow specific IDs to connect to the service and reject all others, set up account policies for specific IDs before you select this setting.
You can create access policies for specified accounts so that the same policy applies to all requests from that account. An account-specific policy takes precedence over the default policy.
Network security
In IBM Cloud, several components control the network traffic that you can use for this scenario.
Security groups
An IBM Cloud security group is a set of IP filter rules that define how to handle incoming (ingress) and outgoing (egress) traffic to both the public and private interfaces of a virtual server instance (VSI) or an application load balancer (ALB).
The rules that you add to a security group are known as security group rules. Each security group consists of two sets of rules: one for inbound and one for outbound traffic. The rules are based on protocol type, a source IP, source port, destination IP, destination port.
Security group rules are permissive and traffic is blocked by default.
Security groups cannot be applied to a Private Path NLB, unlike a standard network load balancer. IBM Cloud creates an implicit rule that the Private Path NLB can accept only connections from the IP address of the VPE in the initiator VPC. This rule is hidden from view and cannot be controlled.
You can apply security groups to the resources that run in the initiator VPC, both the Virtual Private Endpoint and the client. The security groups, in this case, cannot control the network traffic to or from the target VPC, only to or from the client to the Virtual Private Endpoint.
The security group for the ALB implicitly allows access from Private Path NLB when you configure the ALB as member of the Private Path NLB backend-pool, meaning that the rule isn't explicitly listed in the security group but is transparently configured.
To deny all other access to the ALB, avoid adding other permit-rules to this security group.
Access control lists
Use access control lists (ACL) to control all incoming and outgoing traffic in IBM Cloud Virtual Private Cloud. An ACL is a built-in, virtual firewall, similar to a security group. In contrast to security groups, ACL rules control traffic to and from the subnets, rather than to and from the virtual server instances.
ACLs are stateless, which means that you must specify inbound and outbound rules separately and explicitly. Each ACL consists of rules, based on a source IP, source port, destination IP, destination port, and protocol. Firgure 1 summarizes the differences between security groups and access control lists:
You can apply ACLs to the subnets that the Private Path NLB and the ACL use. In this case, allow traffic to flow from the IP addresses or the full subnet of the Private Path NLB to the IP addresses of the front-end listener of the ALB.
You can also apply ACLs to the subnets in the initiator VPC where the VPE on the initiator side is deployed. In this case, the rules cannot control the traffic to the Private Path NLB, only the access to and from the resources in the initiator VPC itself. For example, access from a client to the IP address of the Virtual Private Endpoint.
Configure any on-premises firewall to allow the ALB to reach the on-premises destinations. For example, allow traffic that originates from the subnets that are defined for the ALB.
Data encryption in transit and certificates
To encrypt traffic between the IBM Cloud service and the on-premises application or runtime, the Transport Layer Security (TLS) certificates are hosted on the on-premises target servers. There is no encryption termination on either the Private Path NLB or ALB. The ALB passes on the encrypted traffic, which terminates at the on-premises target. The ALB is configured with a TCP-based front-end listener and TCP-based backend pool.
It is theoretically possible to terminate TLS at the ALB, but the operational overhead that is associated with that approach that does not provide functional benefits, unless, for example, Layer 7 based ALB policies are used.