skills/kubeblocks-configure-tls/SKILL.md
Configure TLS encryption for KubeBlocks database clusters. Supports built-in certificates (auto-managed via cert-manager), user-provided certificates (bring your own CA/PKI), and mTLS (mutual TLS with client certificates). Use when the user wants to enable TLS, SSL, encryption, HTTPS, or secure database connections with certificates. NOT for managing database passwords (see manage-accounts) or exposing services externally (see expose-service).
npx skillsauth add apecloud/kubeblocks-skills kubeblocks-configure-tlsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
KubeBlocks supports TLS encryption for database connections. Three modes are available:
Official docs: https://kubeblocks.io/docs/preview/user_docs/connect-databases/tls-connection
Before proceeding, verify the cluster is healthy and no other operation is running:
# Cluster must be Running
kubectl get cluster <cluster-name> -n <namespace> -o jsonpath='{.status.phase}'
# No pending OpsRequests
kubectl get opsrequest -n <namespace> -l app.kubernetes.io/instance=<cluster-name> --field-selector=status.phase!=Succeed
If the cluster is not Running or has a pending OpsRequest, wait for it to complete before proceeding.
For built-in TLS mode, verify cert-manager is installed:
kubectl get pods -n cert-manager
- [ ] Step 1: Choose TLS mode
- [ ] Step 2: Configure TLS in Cluster CR
- [ ] Step 3: Verify TLS connection
| Mode | Certificate Management | Use Case | |------|----------------------|----------| | Built-in (KubeBlocks) | Automatic via cert-manager | Quick setup, dev/test | | User-provided | Manual (bring your own CA) | Production with existing PKI | | mTLS | Manual + client certs | High-security environments |
cert-manager automates the entire certificate lifecycle — issuance, renewal, and rotation — so you never end up with an expired certificate causing a production outage at 3 AM. Manually managed certificates are fine when you already have a PKI team and established rotation processes, but for most users, cert-manager eliminates a whole class of operational risk. KubeBlocks integrates with cert-manager's Issuer and Certificate CRDs, so enabling TLS is a single field toggle rather than a multi-step manual process.
TLS docs: https://kubeblocks.io/docs/preview/kubeblocks-for-mysql/07-tls/01-tls-overview
The built-in mode requires cert-manager. Install it if not present:
# Check if cert-manager is installed
kubectl get pods -n cert-manager
# Install cert-manager if needed
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/latest/download/cert-manager.yaml
Wait for cert-manager pods to be ready:
kubectl wait --for=condition=Ready pods --all -n cert-manager --timeout=120s
Add TLS configuration to the component spec in the Cluster CR:
spec:
componentSpecs:
- name: <component>
tls: true
issuer:
name: KubeBlocks
This tells KubeBlocks to use cert-manager to automatically generate a self-signed CA and server certificates.
1. Generate certificates (if you don't have them):
# Generate CA key and certificate
openssl genrsa -out ca.key 2048
openssl req -x509 -new -nodes -key ca.key -subj "/CN=MyDatabaseCA" -days 3650 -out ca.crt
# Generate server key and CSR
openssl genrsa -out server.key 2048
openssl req -new -key server.key -subj "/CN=<cluster>-<component>" -out server.csr
# Sign server certificate with CA
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
-CAcreateserial -out server.crt -days 365 \
-extfile <(printf "subjectAltName=DNS:*.<cluster>-<component>-headless.<ns>.svc.cluster.local,DNS:*.<cluster>-<component>.<ns>.svc.cluster.local")
2. Create TLS Secret:
apiVersion: v1
kind: Secret
metadata:
name: <cluster>-tls
namespace: <ns>
type: kubernetes.io/tls
data:
ca.crt: <base64-encoded-ca.crt>
tls.crt: <base64-encoded-server.crt>
tls.key: <base64-encoded-server.key>
Or create it with kubectl:
kubectl create secret generic <cluster>-tls -n <ns> \
--from-file=ca.crt=ca.crt \
--from-file=tls.crt=server.crt \
--from-file=tls.key=server.key
3. Reference in Cluster CR:
spec:
componentSpecs:
- name: <component>
tls: true
issuer:
name: UserProvided
secretRef:
name: <cluster>-tls
ca: ca.crt
cert: tls.crt
key: tls.key
mTLS uses the same server-side TLS configuration (Option A or B), plus requires client certificates.
1. Configure server-side TLS using Option A or B above.
2. Generate client certificates:
# Generate client key and CSR
openssl genrsa -out client.key 2048
openssl req -new -key client.key -subj "/CN=dbclient" -out client.csr
# Sign client certificate with the same CA
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key \
-CAcreateserial -out client.crt -days 365
3. Configure the database to require client certificates:
# MySQL: create user requiring X509
kubectl exec -it <pod> -n <ns> -- mysql -u root -p --ssl -e \
"CREATE USER 'secureuser'@'%' REQUIRE X509; GRANT ALL ON *.* TO 'secureuser'@'%';"
# PostgreSQL: edit pg_hba.conf to require clientcert=verify-full
# This is typically handled via parameter reconfiguration
# MySQL
kubectl exec -it <pod> -n <ns> -- mysql -u root -p --ssl -e "SHOW VARIABLES LIKE '%ssl%';"
# PostgreSQL
kubectl exec -it <pod> -n <ns> -- psql -U postgres -c "SHOW ssl;"
# MySQL with TLS
mysql -h <host> -P 3306 -u root -p --ssl-mode=REQUIRED \
--ssl-ca=ca.crt --ssl-cert=client.crt --ssl-key=client.key
# PostgreSQL with TLS
psql "host=<host> port=5432 user=postgres sslmode=verify-full sslrootcert=ca.crt sslcert=client.crt sslkey=client.key"
# Check the mounted certificates in the pod
kubectl exec -it <pod> -n <ns> -- ls -la /var/run/secrets/tls/
# View certificate info
kubectl exec -it <pod> -n <ns> -- openssl x509 -in /var/run/secrets/tls/tls.crt -text -noout
TLS not enabling (pods crashing):
kubectl describe secret <cluster>-tls -n <ns>kubectl logs <pod> -n <ns>Certificate expired:
Client cannot connect with TLS:
ca.crt must match the server's CAFor engine-specific TLS configuration details, full certificate generation workflows with SANs, and troubleshooting matrix, see reference.md.
For general agent safety conventions (dry-run, status confirmation, production protection), see safety-patterns.md.
devops
Expand persistent volume storage for KubeBlocks database clusters via OpsRequest. Requires the StorageClass to support volume expansion (allowVolumeExpansion=true). Use when the user needs more disk space, wants to increase storage, expand volumes, or resize PVCs. NOT for changing CPU/memory (see vertical-scaling) or adding more replicas (see horizontal-scaling). Note that volume shrinking is not supported by Kubernetes.
data-ai
Scale CPU and memory resources for KubeBlocks database clusters via OpsRequest (vertical scaling). Supports in-place updates when the feature gate is enabled. Use when the user wants to change, increase, decrease, resize, or adjust CPU or memory resources of a database cluster. NOT for adding/removing replicas or shards (see horizontal-scaling) or expanding disk storage (see volume-expansion).
data-ai
Upgrade the KubeBlocks operator itself via Helm. Covers update operator, upgrade to v1.0, update kubeblocks version, and CRD updates. Use when the user wants to upgrade KubeBlocks, update the operator, or upgrade to a new KubeBlocks release. NOT for upgrading database engine versions (see minor-version-upgrade).
development
Diagnostic guide for KubeBlocks-managed database clusters. Use when the user reports troubleshoot, debug, diagnose, not working, error, failed, stuck, CrashLoopBackOff, cluster exception, or similar problems with their database cluster. This skill guides the agent through diagnostic steps — it does NOT perform actions.