Encrypt Traffic Https Load Balancers With Tls Certificates

#!/usr/bin/env bash
#
# Audit HTTPS load balancers and TLS usage for an EKS cluster
# Requirements: kubectl, jq
#
# Run from: any machine with kubectl access and cluster context set

set -euo pipefail

echo "=== 1) List Services of type LoadBalancer and their ports ==="
kubectl get svc -A -o json | jq -r '
  .items[]
  | select(.spec.type=="LoadBalancer")
  | {
      ns: .metadata.namespace,
      name: .metadata.name,
      type: .spec.type,
      ports: .spec.ports,
      ingClass: .metadata.annotations."kubernetes.io/ingress.class",
      scheme: .metadata.annotations."service.beta.kubernetes.io/aws-load-balancer-scheme",
      lbType: .metadata.annotations."service.beta.kubernetes.io/aws-load-balancer-type"
    }
' | jq -c '.'

cat <<'EOF'

Interpretation:
- Any Service of type LoadBalancer exposing TCP port 80 *without* a corresponding HTTPS/TLS termination
  (such as port 443 or annotation-driven TLS) is a potential problem.
- For AWS NLBs, TLS is configured outside Kubernetes; this script only flags that plain TCP 80 is in use.

EOF

echo "=== 2) List Ingresses and TLS configuration ==="
kubectl get ingress -A -o json | jq -r '
  .items[]
  | {
      ns: .metadata.namespace,
      name: .metadata.name,
      class: (
        .spec.ingressClassName
        // .metadata.annotations."kubernetes.io/ingress.class"
      ),
      rules: (
        .spec.rules
        | map({host, paths: (.http.paths | map({path, backend}))})
      ),
      tls: .spec.tls
    }
' | jq -c '.'

cat <<'EOF'

Interpretation (Ingress):
- PROBLEM indicators:
  * An Ingress with hosts under .spec.rules but .spec.tls is null or empty.
  * An Ingress using HTTP (port 80) only, with no TLS section, while it fronts internet‑facing apps.
- OK indicators:
  * .spec.tls is present with at least one host and a secretName (certificate reference).
  * Provider‑specific annotations indicate managed TLS (e.g., ACM certificates), even if .spec.tls is empty.
    You must confirm in the cloud console/IaC that certificates are attached and enforcing HTTPS.

EOF

echo "=== 3) Highlight likely-problem Ingresses (no TLS block) ==="
kubectl get ingress -A -o json | jq -r '
  .items[]
  | select(.spec.rules != null and (.spec.rules | length > 0))
  | select((.spec.tls // []) | length == 0)
  | {
      ns: .metadata.namespace,
      name: .metadata.name,
      class: (
        .spec.ingressClassName
        // .metadata.annotations."kubernetes.io/ingress.class"
      ),
      reason: "Ingress has rules but no .spec.tls block"
    }
' | jq -c '.'

echo
echo "=== 4) Highlight Services of type LoadBalancer exposing port 80 ==="
kubectl get svc -A -o json | jq -r '
  .items[]
  | select(.spec.type=="LoadBalancer")
  | select(
      ([.spec.ports[]?.port] | contains([80]))
    )
  | {
      ns: .metadata.namespace,
      name: .metadata.name,
      ports: .spec.ports,
      annotations: .metadata.annotations,
      reason: "LoadBalancer Service exposes port 80; verify HTTPS/TLS termination at LB"
    }
' | jq -c '.'

cat <<'EOF'

How to read section 4:
- Entries listed here *may* be problems:
  * If they front internet‑facing applications and only expose HTTP (80) with no TLS termination
    at the cloud load balancer, they violate the control.
  * If a managed LB listener redirects 80 -> 443 or terminates TLS with a certificate,
    this is acceptable, but must be verified in the cloud provider console/CLI/IaC.

Next steps (manual review):
- For each flagged Ingress or Service:
  * Check the corresponding load balancer in the cloud provider:
    - Ensure HTTPS listener(s) (e.g., port 443) exist with valid TLS certificates.
    - Ensure HTTP listener (80) is either disabled or redirects to HTTPS.
- This script cannot verify certificates or LB listeners directly; use it to triage
  Kubernetes‑side resources that require cloud‑side inspection.

EOF