mtls-configuration
Install this skill
npx skills add wshobson/agentsWorks across Claude Code, Cursor, Codex, Copilot & Antigravity
The mTLS configuration skill enables identity-based authentication for network traffic within Kubernetes environments. It enforces dual-sided certificate validation between services, ensuring that both client and server verify each other's digital identities before establishing an encrypted tunnel. This approach eliminates reliance on network perimeter security, replacing it with cryptographic validation of workload identity. The skill manages the lifecycle of mutual TLS connections, including certificate issuance via Cert-Manager, policy enforcement through Istio PeerAuthentication, and external service communication via DestinationRules. By automating the rotation and distribution of SVIDs through SPIFFE/SPIRE, this skill maintains continuous secure communication patterns, minimizes the risk of unauthorized traffic interception, and provides an audit trail for inter-service interactions. It provides a standardized method for transitioning legacy clusters into hardened, zero-trust architectures.
When to Use This Skill
- β’Securing internal microservice communication in regulated industries
- β’Implementing zero-trust networking models across multi-cloud clusters
- β’Restricting unauthorized workload access to sensitive databases
- β’Standardizing encrypted transit for legacy applications without native TLS support
How to Invoke This Skill
Example prompts that trigger this skill in Claude Code, Cursor, or Antigravity:
- βConfigure Istio strict mTLS for my cluster
- βHow do I set up mutual TLS for service communication?
- βGenerate a DestinationRule for partner API mTLS
- βHelp me debug TLS handshake failures between these services
- βIntegrate Cert-Manager with Istio for automated certificate management
Pro Tips
- π‘Always automate certificate rotation and renewal to prevent outages and security vulnerabilities.
- π‘Integrate mTLS with a service mesh (e.g., Istio, Linkerd) for fine-grained traffic control and observability.
- π‘Utilize a dedicated secrets management solution (e.g., Vault, AWS Secrets Manager) for storing private keys and CA certificates securely.
What this skill does
- β’Strict peer authentication enforcement for service-to-service traffic
- β’Automation of short-lived certificate issuance and renewal
- β’Dynamic traffic policy management using Istio custom resources
- β’Cross-cluster identity propagation via SPIFFE standards
- β’Namespace-level overrides for incremental security adoption
When not to use it
- βEnvironments where network overhead latency budget is strictly non-existent
- βSimple, non-networked monolith deployments on a single host
- βCases requiring end-to-end user-level TLS termination
Example workflow
- Define the CertificateAuthority and issuer in Cert-Manager
- Deploy PeerAuthentication objects to enforce global or per-namespace strict mTLS
- Create DestinationRule manifests to dictate TLS modes for egress and external traffic
- Monitor proxy logs and metrics to identify handshake or certificate mismatch errors
- Rotate internal identity certificates automatically via service mesh control plane
Prerequisites
- βKubernetes cluster with admin access
- βInstalled Service Mesh (e.g., Istio)
- βConfigured Cert-Manager for PKI operations
- βExisting service-to-service communication setup
Pitfalls & limitations
- !Misconfiguring permissive vs strict mode can lead to immediate traffic blackouts
- !Clock skew between cluster nodes often triggers certificate validation failures
- !Certificate expiration in non-automated setups creates sudden connectivity outages
- !Mismatched SANs or common names in certificates break handshake processes
FAQ
How it compares
Unlike manual certificate management which relies on static files and high maintenance, this skill automates the entire lifecycle through K8s operators, reducing human error during certificate rotation.
π Full skill instructions β original source: wshobson/agents
Comprehensive guide to implementing mutual TLS for zero-trust service mesh communication.
## When to Use This Skill
- Implementing zero-trust networking
- Securing service-to-service communication
- Certificate rotation and management
- Debugging TLS handshake issues
- Compliance requirements (PCI-DSS, HIPAA)
- Multi-cluster secure communication
## Core Concepts
### 1. mTLS Flow
βββββββββββ βββββββββββ
β Service β β Service β
β A β β B β
ββββββ¬βββββ ββββββ¬βββββ
β β
ββββββ΄βββββ TLS Handshake ββββββ΄βββββ
β Proxy ββββββββββββββββββββββββββββββΊβ Proxy β
β(Sidecar)β 1. ClientHello β(Sidecar)β
β β 2. ServerHello + Cert β β
β β 3. Client Cert β β
β β 4. Verify Both Certs β β
β β 5. Encrypted Channel β β
βββββββββββ βββββββββββ### 2. Certificate Hierarchy
Root CA (Self-signed, long-lived)
β
βββ Intermediate CA (Cluster-level)
β β
β βββ Workload Cert (Service A)
β βββ Workload Cert (Service B)
β
βββ Intermediate CA (Multi-cluster)
β
βββ Cross-cluster certs## Templates
### Template 1: Istio mTLS (Strict Mode)
# Enable strict mTLS mesh-wide
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: istio-system
spec:
mtls:
mode: STRICT
---
# Namespace-level override (permissive for migration)
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: legacy-namespace
spec:
mtls:
mode: PERMISSIVE
---
# Workload-specific policy
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: payment-service
namespace: production
spec:
selector:
matchLabels:
app: payment-service
mtls:
mode: STRICT
portLevelMtls:
8080:
mode: STRICT
9090:
mode: DISABLE # Metrics port, no mTLS### Template 2: Istio Destination Rule for mTLS
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: default
namespace: istio-system
spec:
host: "*.local"
trafficPolicy:
tls:
mode: ISTIO_MUTUAL
---
# TLS to external service
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: external-api
spec:
host: api.external.com
trafficPolicy:
tls:
mode: SIMPLE
caCertificates: /etc/certs/external-ca.pem
---
# Mutual TLS to external service
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: partner-api
spec:
host: api.partner.com
trafficPolicy:
tls:
mode: MUTUAL
clientCertificate: /etc/certs/client.pem
privateKey: /etc/certs/client-key.pem
caCertificates: /etc/certs/partner-ca.pem### Template 3: Cert-Manager with Istio
# Install cert-manager issuer for Istio
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: istio-ca
spec:
ca:
secretName: istio-ca-secret
---
# Create Istio CA secret
apiVersion: v1
kind: Secret
metadata:
name: istio-ca-secret
namespace: cert-manager
type: kubernetes.io/tls
data:
tls.crt: <base64-encoded-ca-cert>
tls.key: <base64-encoded-ca-key>
---
# Certificate for workload
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: my-service-cert
namespace: my-namespace
spec:
secretName: my-service-tls
duration: 24h
renewBefore: 8h
issuerRef:
name: istio-ca
kind: ClusterIssuer
commonName: my-service.my-namespace.svc.cluster.local
dnsNames:
- my-service
- my-service.my-namespace
- my-service.my-namespace.svc
- my-service.my-namespace.svc.cluster.local
usages:
- server auth
- client auth### Template 4: SPIFFE/SPIRE Integration
# SPIRE Server configuration
apiVersion: v1
kind: ConfigMap
metadata:
name: spire-server
namespace: spire
data:
server.conf: |
server {
bind_address = "0.0.0.0"
bind_port = "8081"
trust_domain = "example.org"
data_dir = "/run/spire/data"
log_level = "INFO"
ca_ttl = "168h"
default_x509_svid_ttl = "1h"
}
plugins {
DataStore "sql" {
plugin_data {
database_type = "sqlite3"
connection_string = "/run/spire/data/datastore.sqlite3"
}
}
NodeAttestor "k8s_psat" {
plugin_data {
clusters = {
"demo-cluster" = {
service_account_allow_list = ["spire:spire-agent"]
}
}
}
}
KeyManager "memory" {
plugin_data {}
}
UpstreamAuthority "disk" {
plugin_data {
key_file_path = "/run/spire/secrets/bootstrap.key"
cert_file_path = "/run/spire/secrets/bootstrap.crt"
}
}
}
---
# SPIRE Agent DaemonSet (abbreviated)
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: spire-agent
namespace: spire
spec:
selector:
matchLabels:
app: spire-agent
template:
spec:
containers:
- name: spire-agent
image: ghcr.io/spiffe/spire-agent:1.8.0
volumeMounts:
- name: spire-agent-socket
mountPath: /run/spire/sockets
volumes:
- name: spire-agent-socket
hostPath:
path: /run/spire/sockets
type: DirectoryOrCreate### Template 5: Linkerd mTLS (Automatic)
# Linkerd enables mTLS automatically
# Verify with:
# linkerd viz edges deployment -n my-namespace
# For external services without mTLS
apiVersion: policy.linkerd.io/v1beta1
kind: Server
metadata:
name: external-api
namespace: my-namespace
spec:
podSelector:
matchLabels:
app: my-app
port: external-api
proxyProtocol: HTTP/1 # or TLS for passthrough
---
# Skip TLS for specific port
apiVersion: v1
kind: Service
metadata:
name: my-service
annotations:
config.linkerd.io/skip-outbound-ports: "3306" # MySQL## Certificate Rotation
# Istio - Check certificate expiry
istioctl proxy-config secret deploy/my-app -o json | \
jq '.dynamicActiveSecrets[0].secret.tlsCertificate.certificateChain.inlineBytes' | \
tr -d '"' | base64 -d | openssl x509 -text -noout
# Force certificate rotation
kubectl rollout restart deployment/my-app
# Check Linkerd identity
linkerd identity -n my-namespace## Debugging mTLS Issues
# Istio - Check if mTLS is enabled
istioctl authn tls-check my-service.my-namespace.svc.cluster.local
# Verify peer authentication
kubectl get peerauthentication --all-namespaces
# Check destination rules
kubectl get destinationrule --all-namespaces
# Debug TLS handshake
istioctl proxy-config log deploy/my-app --level debug
kubectl logs deploy/my-app -c istio-proxy | grep -i tls
# Linkerd - Check mTLS status
linkerd viz edges deployment -n my-namespace
linkerd viz tap deploy/my-app --to deploy/my-backend## Best Practices
### Do's
- **Start with PERMISSIVE** - Migrate gradually to STRICT
- **Monitor certificate expiry** - Set up alerts
- **Use short-lived certs** - 24h or less for workloads
- **Rotate CA periodically** - Plan for CA rotation
- **Log TLS errors** - For debugging and audit
### Don'ts
- **Don't disable mTLS** - For convenience in production
- **Don't ignore cert expiry** - Automate rotation
- **Don't use self-signed certs** - Use proper CA hierarchy
- **Don't skip verification** - Verify the full chain
## Resources
- [Istio Security](https://istio.io/latest/docs/concepts/security/)
- [SPIFFE/SPIRE](https://spiffe.io/)
- [cert-manager](https://cert-manager.io/)
- [Zero Trust Architecture (NIST)](https://www.nist.gov/publications/zero-trust-architecture)
How to Use This Skill Unit
Option A: Project-Specific (Recommended)
- Click "Download" above
- In your project, create the directory:
.agent/skills/mtls-configuration/ - Save the file as
SKILL.md - The agent will automatically discover the skill based on its description.
Option B: Global Installation (All Agents)
Save the file to these locations to make it available across all projects:
- Claude Code:
~/.claude/skills/wshobson/agents/mtls-configuration/SKILL.md - Cursor:
~/.cursor/skills/wshobson/agents/mtls-configuration/SKILL.md - Antigravity:
~/.gemini/antigravity/skills/wshobson/agents/mtls-configuration/SKILL.md
π Install with CLI:npx skills add wshobson/agents
