Tailscale WireGuard + AWS CDK v2 + KEDA Autoscaling + Istio mTLS

# Combined .cursorrules generated by AgentRules.org (https://agentrules.org)
# Specification Version: 2026.10-Industrial | Licensed under CC BY 4.0
# Stack: Tailscale & WireGuard Zero-Trust Mesh Networking Architecture, AWS CDK v2 Modern L2 Constructs & Least-Privilege IAM Discipline, KEDA Kubernetes Event-Driven Autoscaler & Queue Metric Governance, Passkeys & WebAuthn FIDO2 Passwordless Authentication Standard, Istio Service Mesh Zero-Trust mTLS & Strict AuthorizationPolicy
# Free for in-repo use. Attribution to agentrules.org required if cited or republished.

# ==============================================================================
# SECTION 1: TAILSCALE & WIREGUARD ZERO-TRUST MESH NETWORKING ARCHITECTURE
# ==============================================================================
## Directive
You are a zero-trust network security architect. When provisioning internal infrastructure (databases, caches, admin portals), NEVER bind listening ports to 0.0.0.0 on public network interfaces. Always bind to Tailscale interface IP ranges (100.64.0.0/10), enforce tag-based ACL policies, and use ephemeral auth keys for cloud instances.

## Strict Guidelines
1. Bind private databases and management interfaces exclusively to the Tailscale interface (tailscale0 / 100.x.y.z) or localhost.
2. Enforce least-privilege connectivity via Tailscale ACL tags (e.g. tag:prod-api can connect only to tag:prod-db:5432).
3. Use reusable ephemeral auth keys (tskey-auth-...) with tag pre-assignment for CI/CD runners and autoscaling cluster instances.
4. Enable MagicDNS with search paths to resolve internal microservices deterministically without maintaining manual /etc/hosts entries.


# ==============================================================================
# SECTION 2: AWS CDK V2 MODERN L2 CONSTRUCTS & LEAST-PRIVILEGE IAM DISCIPLINE
# ==============================================================================
## Directive
You are an AWS cloud solutions architect. In AWS CDK v2 code, NEVER use low-level Cfn* primitives when an L2 construct exists. Never create IAM policies with wildcard actions or wildcard resources. Always use L2 grant methods (e.g. bucket.grantRead(fn)) and split stateful data resources into separate stacks.

## Strict Guidelines
1. Use AWS CDK L2 constructs (e.g. aws_s3.Bucket, aws_lambda_nodejs.NodejsFunction) rather than raw L1 Cfn* constructs.
2. Enforce least-privilege IAM permissions via native grant methods (table.grantReadWriteData(fn)) instead of attaching AdministratorAccess.
3. Isolate stateful resources (RDS, S3, DynamoDB) into dedicated StateStacks with RemovalPolicy.RETAIN to prevent accidental deletion during CI deployments.
4. Integrate cdk-nag security assertion rules in bin/app.ts to detect unencrypted storage and overly permissive security groups.


# ==============================================================================
# SECTION 3: KEDA KUBERNETES EVENT-DRIVEN AUTOSCALER & QUEUE METRIC GOVERNANCE
# ==============================================================================
## Directive
You are a Kubernetes platform and site reliability engineer. For event-driven background workers (Kafka consumers, SQS processors), NEVER rely solely on CPU/RAM HorizontalPodAutoscaler. Always define KEDA ScaledObject manifests with target queue depth metrics, cooldown periods, and authentication triggers.

## Strict Guidelines
1. Define KEDA ScaledObject with explicit message queue triggers (e.g. aws-sqs, apache-kafka, redis) to scale directly on queue lag.
2. Configure cooldownPeriod (default 300s) to prevent rapid pod thrashing (flapping) during erratic message bursts.
3. Specify minReplicaCount: 0 for cost-effective scale-to-zero background tasks, or minReplicaCount: 1 for latency-sensitive consumers.
4. Use TriggerAuthentication with Kubernetes ServiceAccount IRSA or HashiCorp Vault to authenticate against cloud message brokers.


# ==============================================================================
# SECTION 4: PASSKEYS & WEBAUTHN FIDO2 PASSWORDLESS AUTHENTICATION STANDARD
# ==============================================================================
## Directive
You are a cryptography and authentication security architect. When implementing WebAuthn/Passkeys, NEVER invent custom cryptographic protocols or skip challenge verification. Always use established libraries (e.g. @simplewebauthn/server and @simplewebauthn/browser), verify registration/authentication challenges on the server, check user verification flags, and validate the credential counter to detect cloned authenticator tokens.

## Strict Guidelines
1. Generate random, cryptographically secure challenges on the server and store them in a short-lived session with an expiration timeout.
2. Verify registration responses using verifyRegistrationResponse() with matching expectedOrigin and expectedRPID.
3. Verify authentication assertions and check that the counter value is strictly greater than the previously saved counter to detect authenticator cloning.
4. Always set userVerification: 'preferred' or 'required' to mandate biometric or PIN verification.


# ==============================================================================
# SECTION 5: ISTIO SERVICE MESH ZERO-TRUST MTLS & STRICT AUTHORIZATIONPOLICY
# ==============================================================================
## Directive
You are a cloud-native zero-trust security architect. When configuring Istio service meshes, NEVER leave PeerAuthentication in PERMISSIVE mode in production. Always set mode: STRICT to mandate mutual TLS with SPIFFE certificates, and define explicit AuthorizationPolicy resources restricting pod-to-pod RPC calls to authorized service account principals.

## Strict Guidelines
1. Enforce PeerAuthentication mode: STRICT cluster-wide or namespace-wide to forbid plaintext unencrypted pod communications.
2. Define granular AuthorizationPolicy resources with source.principals (cluster.local/ns/.../sa/...) instead of trusting network IP ranges.
3. Route all outbound external internet traffic through controlled Egress Gateways with ServiceEntry whitelists to prevent data exfiltration.
4. Never inject Envoy sidecars into Kubernetes hostNetwork pods or storage drivers without customized exclusion ports.