Skip to main content

​
Overview

K8SaaS security encompasses multiple layers: TLS encryption for all cluster API communication, Kubernetes RBAC within clusters, network-level restrictions via security groups, and hardened node images. This page covers the key security controls and how to verify they are correctly applied across your K8SaaS deployment.
Security misconfigurations in K8SaaS can expose Kubernetes API servers to unauthorized access or allow cross-tenant privilege escalation. Review each control before deploying production clusters.

​
TLS Configuration

All K8SaaS cluster API communication is TLS-encrypted. Each cluster has a dedicated CA generated at provisioning time.

Verify TLS on the API server

Check API server TLS certificate
openssl s_client -connect <api-address>:6443 \
  -showcerts 2>/dev/null \
  | openssl x509 -noout -issuer -subject -dates
Verify the certificate is issued by the cluster’s CA (not a self-signed root) and has not expired.
Enable Xloud Key Management to store CA private keys outside the K8SaaS database. This prevents CA private keys from being accessible to anyone with database read access.

Enable KMS

Navigate to XDeploy → Configuration → Advance Features and set Enable KMS to Yes.

Configure certificate manager

Navigate to XDeploy → Advanced Configuration, select magnum in the Service Tree, then open or create kubernetes.conf. Add the following:
kubernetes.conf
[certificate]
cert_manager_type = barbican
Click Save Current File.

Deploy

Run XDeploy → Operations → Reconfigure for both the Key Management and Kubernetes services.

​
Kubernetes RBAC

Kubernetes RBAC is enabled by default on all K8SaaS clusters. The --authorization-mode flag is set to Node,RBAC in the Kubernetes API server configuration.

Enforce least-privilege service accounts

Do not grant the cluster-admin role to application service accounts. Use namespace-scoped roles and bindings:
Namespace-scoped role example
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: app-reader
rules:
- apiGroups: [""]
  resources: ["pods", "services"]
  verbs: ["get", "list", "watch"]
Check for overly broad cluster-admin bindings
kubectl get clusterrolebindings \
  -o json | jq -r '.items[] | select(.roleRef.name == "cluster-admin") | .metadata.name'
Periodically audit cluster role bindings to identify unauthorized privilege escalation:
List all cluster-level role bindings
kubectl get clusterrolebindings -o wide
Find service accounts with admin privileges
kubectl get clusterrolebindings \
  -o json | jq -r '.items[] | select(.roleRef.name | startswith("cluster-admin")) | "\(.metadata.name): \(.subjects[].name)"'

​
Node Security Groups

Each K8SaaS cluster creates dedicated security groups for master and worker nodes. Review and restrict these groups to permit only required traffic.
List cluster security groups
openstack security group list \
  | grep <cluster-name>

​
Required Ports

PortProtocolDirectionPurpose
6443TCPInbound to mastersKubernetes API server (kubectl, kubelets)
2379-2380TCPMaster to masteretcd peer and client communication
10250TCPMaster to workerskubelet API
10255TCPAny (optional)kubelet read-only API (disable if not needed)
VXLAN / BGPUDP/TCPNode to nodeCNI overlay (Flannel) or BGP peering (Calico)
Restrict master API port to management CIDR only
openstack security group rule create \
  --protocol tcp \
  --dst-port 6443 \
  --remote-ip <management-cidr> \
  <master-security-group-id>
Remove any overly permissive rule
openstack security group rule delete <rule-id>

​
Node Image Hardening

Use CIS-benchmarked or hardened node images for production cluster templates.

Use Hardened Images

Use images with CIS Level 1 benchmark applied. Fedora CoreOS provides a minimal, immutable OS — a good baseline for Kubernetes node hardening.

Rotate Images on Security Updates

When node OS security updates are released, create a new cluster template with the updated image and upgrade existing clusters to replace all nodes.

​
Validation Checklist

TLS verified

API server TLS certificate is valid, issued by the cluster CA, and not expired.

RBAC audited

No unnecessary cluster-admin bindings exist for application service accounts.

Security groups restricted

Master API port 6443 is restricted to management CIDR only.

Key Management configured

CA private keys stored in Xloud Key Management, not the K8SaaS database.

​
Next Steps

Certificates

Manage and rotate cluster CA certificates.

Monitoring

Monitor cluster health and audit security events.

Network Drivers

Configure Calico for NetworkPolicy enforcement in production clusters.

Key Manager

Configure Xloud Key Management for cluster CA storage.