Back to Security & Vulnerability Analysis

mtls-configuration

mTLSTLSzero-trustsecuritymicroservicesnetworkingcertificatesservice mesh
⭐ 36.8kπŸ“„ MITπŸ•’ 2026-06-16Source β†—

Install this skill

npx skills add wshobson/agents

Works 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

  1. Define the CertificateAuthority and issuer in Cert-Manager
  2. Deploy PeerAuthentication objects to enforce global or per-namespace strict mTLS
  3. Create DestinationRule manifests to dictate TLS modes for egress and external traffic
  4. Monitor proxy logs and metrics to identify handshake or certificate mismatch errors
  5. 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

What is the difference between PERMISSIVE and STRICT mode?
PERMISSIVE allows both plain-text and mTLS traffic, facilitating migrations, whereas STRICT rejects any traffic that is not encrypted and verified with a valid certificate.
Do I need SPIRE if I am using Istio?
Not necessarily; Istio provides its own internal CA for certificate issuance. SPIRE is primarily used for cross-platform identity federation or advanced workload attestation.
Why does my handshake fail when connecting to external APIs?
Usually because the DestinationRule for that external host is missing the required CA certificates or client identity files for mutual verification.

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.

Source & trust

⭐ 37k starsπŸ“„ MITπŸ•’ Updated 2026-06-16
πŸ“„ Full skill instructions β€” original source: wshobson/agents
# mTLS Configuration

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)

  1. Click "Download" above
  2. In your project, create the directory: .agent/skills/mtls-configuration/
  3. Save the file as SKILL.md
  4. 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

Read the Master Guide: Mastering Agent Skills β†’

Related Skill Units

Recommended Rules

View more rules β†’

Recommended Workflows

View more workflows β†’

Recommended MCP Servers

View more MCP servers β†’

Take It Further

Maximize your productivity with these powerful resources

πŸ“‹

Define Your Standards

Set up coding standards to ensure this workflow produces consistent, high-quality results.

Browse Rules Library
πŸ“–

Master Workflows

Learn how to create custom workflows, use Turbo Mode, and build your automation library.

Complete Guide

How to use this Skill in Claude Code & Cursor

For Claude Code (CLI)

To use this skill in Claude Code, copy the rule content into your project's custom instructions or follow our Add-Skill CLI guide. This ensures Claude follows your standards during every code generation.

For Cursor & Windsurf

For Cursor or Windsurf, individual skills are best used in the "Rules for AI" section. This specific unit helps the agent avoid security & vulnerability analysis issues, leading to cleaner, more efficient code.

Why the skill format matters: the standardized Agent Skills format lets your AI agent load detailed instructions only when they are relevant, keeping your prompt clean while improving results.

Source & attribution

This skill is categorized under Security & Vulnerability Analysis and is published by W. Shobson, maintained in wshobson/agents.

← Browse All Agent Skills
Sponsored AI assistant. Recommendations may be paid.