CloudRaya Documentation

Ingress & TLS Security

Ingress is the primary security boundary for publicly exposed Kubernetes applications.

When users access your application from the internet, Ingress is the first component they hit.

This makes Ingress the ideal place to enforce HTTPS, apply TLS certificates, and control traffic securely.

This guide explains:

  • How TLS works with Kubernetes Ingress
  • Where HTTPS termination happens
  • How to use domains and certificates safely
  • Common mistakes to avoid when securing Ingress

Why TLS Matters for Ingress

Without TLS, traffic between users and your application is:

  • Unencrypted
  • Vulnerable to interception
  • Susceptible to man-in-the-middle attacks

TLS ensures:

  • Encrypted communication (HTTPS)
  • Server identity verification
  • Data integrity in transit

For any internet-facing Kubernetes service, TLS should be considered mandatory, not optional.

How Ingress and TLS Work Together

Ingress operates at Layer 7 (HTTP/HTTPS) and is designed to handle:

  • Host-based routing
  • Path-based routing
  • TLS termination

Typical Secure Traffic Flow

Internet
  ↓ HTTPS
Ingress Controller (TLS termination)
  ↓ HTTP
Service (ClusterIP)

Pods

Key points:

  • TLS is terminated at the Ingress layer
  • Backend services remain private
  • Pods do not need public certificates

This design centralizes security and simplifies certificate management.

Domain Names and TLS Certificates

Internal vs Public Domains

ScopeDomain TypeTLS Required
Internal services.svc.cluster.local❌ No
Public servicesCustom domain✅ Yes

Kubernetes does not provide public domain names.

For public access:

  • You must purchase a domain from a domain provider
  • DNS records must point to:
    • Ingress IP, or
    • LoadBalancer IP

Example:

app.example.com → Ingress IP → Service → Pods

Configuring TLS with Ingress

TLS is configured inside the Ingress resource.

Basic TLS Ingress Example

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
spec:
  tls:
    - hosts:
        - app.example.com
      secretName: app-tls
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-service
                port:
                  number: 80

Explanation:

  • hosts defines the public domain
  • secretName references a TLS certificate stored as a Kubernetes Secret
  • Traffic is encrypted externally and routed internally

TLS Certificate Management

TLS certificates are stored as Kubernetes Secrets.

Certificate Sources

You can obtain certificates from:

  • Commercial Certificate Authorities
  • Automated providers (e.g., Let’s Encrypt)
  • Internal PKI (for enterprise environments)

Ingress simply consumes the certificate, it does not issue it.

Best Practices

  • Store certificates as Secrets
  • Rotate certificates before expiration
  • Use automation where possible
  • Avoid embedding certificates directly in manifests

Common Ingress & TLS Security Mistakes

Avoid these frequent issues:

Exposing Services Without TLS

  • HTTP-only endpoints
  • Plaintext credentials
  • Increased attack surface

Using NodePort Instead of Ingress

  • No TLS termination
  • Harder to manage certificates
  • Poor scalability

Terminating TLS Inside the Application

  • Duplicated certificate management
  • Inconsistent security
  • Harder rotation and auditing

Ingress should handle TLS, not individual pods.

Using Wildcard or Overly Broad Rules

  • Excessive host matching
  • Accidental exposure of services

Always scope Ingress rules carefully.

Security Hardening Recommendations

For production workloads:

  • Always use Ingress + TLS
  • Prefer HTTPS-only endpoints
  • Redirect HTTP → HTTPS
  • Limit exposed paths and hosts
  • Combine with:
    • Authentication
    • Authorization
    • Rate limiting (if supported)
  • Keep backend services private (ClusterIP)

Ingress should act as a controlled gateway, not an open door.

How This Fits in KubeRaya

In KubeRaya:

  • Ingress uses Kubernetes-native networking
  • Public exposure is explicit
  • TLS is fully supported via standard Kubernetes constructs
  • No dependency on CloudRaya VM Load Balancer service

Ingress security follows upstream Kubernetes best practices, ensuring portability and compatibility.

When to Revisit Your Ingress Security

Review your Ingress and TLS configuration when:

  • Adding new domains
  • Introducing public APIs
  • Scaling applications
  • Rotating certificates
  • Investigating security incidents

Ingress is not “set and forget”.

Summary

  • Ingress is the primary entry point for public Kubernetes traffic
  • TLS should always be enabled for public services
  • TLS termination belongs at the Ingress layer
  • Proper Ingress design reduces security risk
  • Secure defaults lead to safer production systems

A secure Ingress setup is the foundation of a secure Kubernetes deployment.

📄 Expose Services in Kubernetes

📄 Networking in Kubernetes

📄 Kubernetes Security Basics

📄 Kubernetes Best Practices

© 2026 CloudRaya Product Team. All rights reserved.

On this page