Scott's Weblog The weblog of an IT pro focusing on cloud computing, Kubernetes, Linux, containers, and networking

Fine-Tuning Control Plane Access with Cluster API

When Cluster API creates a workload cluster, it also creates a load balancing solution to handle traffic to the workload cluster’s control plane. This is necessary so that the control plane endpoint is decoupled from the underlying control plane nodes (which facilitates scaling the control plane, among other things). On AWS, this mean creating an ELB and a set of security groups. For flexibility, Cluster API provides a limited ability to customize this control plane load balancer. In this post, I’ll show you how to use this functionality to fine-tune access to a workload cluster’s control plane when using Cluster API with AWS.

If you’re not familiar with Cluster API (hereafter just referred to as “CAPI”), then my introduction to CAPI article may be useful. Keep in mind that article was written in 2019, while the project was still in its early stages. The high-level concepts are correct, but some of the details may have shifted slightly over the last three years as the project progressed from v1alpha1 APIs to the now-current v1beta1 APIs.

The key here is the controlPlaneLoadBalancer object, which is part of the AWSCluster object (see details here in the code or here via With regard to access to a workload cluster’s control plane via its control plane load balancer, two fields are of particular interest:

  1. The additionalSecurityGroups field allows you to list any additional security groups—referenced by security group ID—that the control plane load balancer should use (this is in addition to the standard set of security groups created by CAPI). This is an optional field.
  2. The scheme field allows you to specify whether the load balancer should be externally-accessible from the Internet (specified with the value “internet-facing”, which is the default value) or not (specified with the value “internal”). If you specify “internal” as the scheme, then the load balancer won’t get a public IP address and won’t be reachable via the Internet. This would be a great way to restrict access to only those connections coming via a VPN (or similar) into the VPC.

Personally, I would at least switch the scheme on the control plane load balancer; otherwise, the API server of your newly-created workload cluster is publicly accessible via the Internet. You can then leverage any additional security groups as needed.

One note to keep in mind: the default security group created by the AWS provider for CAPI (referred to as CAPA) allows access from to the control plane load balancer. If you need to restrict access to something more fine-grained than that, using the additionalSecurityGroups field is not the way. As outlined here, you’ll instead want to use the securityGroupOverrides field (which is found at

I hope this information is useful. Feel free to reach out to me if you have any questions (or corrections, in the event I explained/presented something incorrectly). You can find me on the Kubernetes Slack (as well as a number of other Slack communities) as well as on Twitter.

Metadata and Navigation

Be social and share this post!