Skip to content

Private deployment

For customers who require an extra layer of security, we offer the option to deploy a private stack that is not accessible from the public internet.

Architecture

The main difference in the architecture lies in how connections are established and how communication is established between different layers of management clusters (Garden, Seeds) and shoots in private stack.

In the private stack all management clusters endpoints utilize the private node subnet of the specific cluster in which they are running. This is achieved through the functionality of a private/internal loadbalancer.

image

The picture above illustrates how the connection works for a private stack. Customers connect to their tenant (Garden cluster) via a VPN established by the OSC team, based on information about the "Customer VPN endpoint", which needs to be created and managed by the customer.

The endpoints of the Garden cluster are deployed using an internal load balancer that allocates IP addresses from the Garden cluster's private subnet. The Garden clusters are connected to the seed through peering, which enables internal interconnections of private networks within the OSC environment, and the seed is connected to each shoot in the similar way as Garden cluster via separate peering.

Customer requirements/responsibilities

Based on the information described above, there are some requirements and limitations that must be taken into consideration before deploying the stack:

  • Establish a "Customer VPN endpoint": A public endpoint that will be used as one end of the VPN and is fully under the customer's control and responsibility.

  • Create a request for establishing the VPN, including information about the "Customer VPN endpoint":

    1. Public IP of the "Customer VPN endpoint". In case of HA VPN please provide both public IPs.
    2. Remote subnet (the private network of the "Customer VPN endpoint").
    3. IKE (Internet Key Exchange) and ESP (Encapsulating Security Payload): Both VPN sides must have the same configuration, including algorithms and lifecycle settings, which can be provided by the customer to the OSC or vice versa. Algorithm should looks like the example below. Note: ecp521 equals to Diffie-Hellman Group 21.
    4. Pre-shared key: This needs to be the same on both sides and can be generated on the OSC side and provided to the customer.
    5. NAT - optional (mostly applicable for cisco vpn solutions) - if used please provide also NAT address of Remote gateway.

    Example of IKE and ESP

           IKE: aes256-sha512-ecp521
       ESP: aes256-sha512-ecp521

  • Network plan for shoots, with the following rules to be followed:

    1. Shoots located on the same seed must have different subnets that do not overlap. Each shoot has separate peering, meaning communication towards seed will work even if both shoots have the same shoot node subnet. However, a problem arises with communication from the seed to the shoot, as the seed will not be able to distinguish whether communication needs to be sent to one shoot or another if they have the same node subnet. The reason is that shoot node subnets are managed independently (private subnets), and probability of a situation where both shoots utilize the same IP for node or even for internal loadbalancer is high.
    2. The fact that the stack is private does not automatically mean that all workloads on the shoot cluster are private. If the customer deploys a service of type "LoadBalancer", it will, by default, create a publicly available loadbalancer with a public IP on the infrastructure layer. To ensure that all endpoints (ingresses or services) are private, they must be deployed using a private/internal loadbalancer
    3. The node subnet of the shoot cluster needs to be sufficiently large. It needs to not only cover the number of planned nodes but also meet the requirements for a private/internal loadbalancers if planned.