You can configure a Kubernetes service of type LoadBalancer to use a static IP address. Be aware of minimum component requirements, an important security consideration and cluster hardening guidance before implementing this feature.
|Component||Minimum Requirement||More Information|
|vCenter Server and ESXi||vSphere 7.0 Update 2||See the Release Notes.|
||See Update the Supervisor Cluster by Performing a vSphere Namespaces Update.|
NSX-T Data Center v3.1
NSX Advanced 20.1.x
|See the Release Notes.|
|Tanzu Kubernetes Release||One of the latest Tanzu Kubernetes releases.||See List of Tanzu Kubernetes releases.|
Using a Static IP for a Service of Type LoadBalancer
Alternatively you can specify a static IP address for the load balancer. On creation of the service, the load balancer instance is provisioned with the static IP address you assigned.
loadBalancerIPparameter and an IP address value, which is
10.11.12.49in this example.
kind: Service apiVersion: v1 metadata: name: load-balancer-service-with-static-ip spec: selector: app: hello-world tier: frontend ports: - protocol: "TCP" port: 80 targetPort: 80 type: LoadBalancer loadBalancerIP: 10.11.12.49
For the NSX Advanced load balancer, you use a IP address from the IPAM pool configured for the load balancer when it was installed. When the service is created and the static IP address is assigned, the load balancer marks it as allocated and manages the lifecycle of the IP address the same way it does an ephemeral IP address. That is, if the service is removed, the IP address is unassigned and made available for reallocation.
For the NSX-T load balancer, you have two options. The default mechanism is the same as the NSX Advanced load balancer: use an IP address taken from the IP pool configured for the load balancer when it was installed. When the static IP address is assigned, the load balancer automatically marks it as allocated and manages its lifecycle.
The second NSX-T option is to manually pre-allocate the static IP address. In this case you use an IP address that is not part of the external load balancer IP pool assigned to load balancer, but instead taken from a floating IP pool. In this case you manually administer the allocation and lifecycle of the IP address using the NSX Manager.
Important Security Consideration and Hardening Requirement
There is a potential security issue to be aware of when using this feature. If a developer is able to patch the
Service.status.loadBalancerIP value, the developer may be able to hijack the traffic in the cluster destined for the patched IP address. Specifically, if a Role or ClusterRole with the
patch permission is bound to a service or user account on a cluster where this feature is implemented, that account owner is able to use its own credentials to issue
kubectl commands and change the static IP address assigned to the load balancer.
To avoid the potential security implications of using static IP allocation for a load balancer service, you must harden each cluster where you are implementing this feature. To do this, the Role or ClusterRole you define for any developer must not allow the
patch verb for
resources: services/status. The example role snippet demonstrates what not to do when implementing this feature.
- apiGroups: - "" resources: - services/status verbs: - patch
kubectl --kubeconfig <KUBECONFIG> auth can-i patch service/status
If the command returns
yes, the user has patch permissions. See Checking API Access in the Kubernetes documentation for more information.
To grant developer access to a cluster, see Grant Developer Access to Tanzu Kubernetes Clusters. For a sample Role template that you can customize, see Example Role for Pod Security Policy. For an example on how to restrict cluster access, see https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-example.