Configure access control for your cluster

The access control feature of SKE enables an additional layer of security for your Kubernetes clusters by limiting access to the Kubernetes API. In this article, we’ll show you how to enable and configure access control.

ACLs only control access to the API of the public control plane. You cannot combine ACLs with a private control plane (accessScope: "SNA"), because the two features are mutually exclusive. You can use ACLs with a public cluster, or use a private cluster without ACLs. For more details, read the SKE networking and private clusters documentation.

Configuring access control via SKE API

The access control feature is available via the SKE API as an extension. Refer to the following example of a cluster object. We omitted some fields for clarity:

{
  "name": "example-cluster",
  "kubernetes": {...},
  "nodepools": [...],
  "maintenance": {...},
  "extensions": {
    "acl": {
      "enabled": true,
      "allowedCidrs": [
        "198.51.100.0/24",
        "203.0.113.10/32"
      ]
    }
  }
}

This cluster object specifies and enables the acl extension. ACL stands for access control list. Note that the field enabled has to be set to true for the extension to have an effect.

To enable access control, send a PUT request to the SKE API that contains a cluster object which has the ACL extension enabled and configured. Please read on to learn how to determine which entries you need to add for allowedCidrs.

Configuring access control via Terraform

ACLs are also supported by the Terraform Provider. The field names differ between API and Terraform:

• API: allowedCidrs
• Terraform: allowed_cidrs

extensions = {
  acl = {
    enabled       = true
    allowed_cidrs = ["203.0.113.10/32"]
  }
}

See the Terraform stackit_ske_cluster documentation for details.

Specifying allowed CIDRs

Take a look at the field allowedCidrs. CIDR is an abbreviation for Classless Inter Domain Routing, which - among other things - describes the notation for specifying IP ranges used here. Every entry in this list specifies an IP range, consisting of an IP (for example: 198.51.100.0) and a suffix (for example: /24). The suffix denotes the size of the range. All requests that origin from an IP within one of the specified ranges are allowed to connect to the Kubernetes API server. In the above example, this means:

• 198.51.100.0/24 → All IPs in the range from 198.51.100.0 to 198.51.100.255 are allowed.
• 203.0.113.10/32 → The single IP 203.0.113.10 is allowed.

As you can see, with a suffix of /32 you can allow single IP addresses, which allows for the most fine-grained configuration. If you’re unsure about the correct CIDR notation for the IP range you have in mind, consider using an online converter (for example, ipaddressguide.com).

Make sure to allow the source IPs that actually reach the Kubernetes API server. This includes corporate NAT gateways, VPN egress addresses, bastion hosts, and CI/CD pipeline egress addresses. Private RFC1918 CIDRs only work if the traffic really reaches the API server from that network.

Lockout risk! Enabling ACLs with an empty or wrong allowedCidrs list can lock out all clients, including yourself. Make sure at least your own reachable source IP is included before enabling ACLs. After applying the change, verify access from a second, allowed client before ending your session.

Safe update workflow

To avoid accidentally overwriting other cluster fields, follow this workflow:

1. Retrieve the existing cluster configuration or generate a payload via the STACKIT CLI:

   stackit ske cluster generate-payload

2. Change only the extensions.acl section.

3. Send the update, for example with the STACKIT CLI:

   stackit ske cluster update <cluster-name> -p <project-id> --payload @payload.json

4. Test access with one allowed and one non-allowed client to verify the ACL works as expected.

Refer to the STACKIT CLI ske cluster update documentation and the SKE API documentation for more information.