Section 4: Exposing the Deployment

Overview:

By default, your Kubernetes deployment is only accessible from within the cluster. To allow external applications (e.g. mobile apps, identity providers, or API consumers) to communicate with the cryptonets-api, you need to expose it using a Kubernetes Service — and optionally an Ingress for domain-based routing and TLS.

This section includes:

• A basic LoadBalancer service (for fast external access)
• An optional Ingress setup (for HTTPS, domain names, and centralized routing)

Choose the method that aligns with your environment and security model.

Step 4.1: Expose via a LoadBalancer Service

This approach provisions a cloud-native load balancer (e.g., ELB, GCLB, Azure LB) and assigns a public IP to the service.

  apiVersion: v1
  kind: Service
  metadata:
    name: privateid-api-service
    labels:
      app: privateid-api
  spec:
    type: LoadBalancer
    selector:
      app: privateid-api
    ports:
      - protocol: TCP
        port: 80            # Exposed externally
        targetPort: 8080    # Inside the container

Apply it:

  kubectl apply -f service.yaml

Then fetch the external IP:

  kubectl get svc privateid-api-service

Note: Provisioning a LoadBalancer can take 1–3 minutes depending on the cloud provider.

Step 4.2: Optional — Set Up an Ingress Resource

If you're managing multiple services, using custom domain names, or need TLS termination, Ingress is the better approach.

Example Ingress for NGINX Ingress Controller:

  apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
    name: privateid-api-ingress
    annotations:
      nginx.ingress.kubernetes.io/rewrite-target: /
  spec:
    rules:
    - host: api.privateid.yourdomain.com
      http:
        paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: privateid-api-service
              port:
                number: 80

To enable HTTPS, you’ll need a TLS secret and a certificate issuer like cert-manager or Let's Encrypt:

  tls:
    - hosts:
      - api.privateid.yourdomain.com
      secretName: privateid-api-tls

Step 4.3: Security Considerations for Public Exposure

If the API should not be open to the internet, consider:

• API Gateway or mTLS authentication
• Internal load balancer (service.beta.kubernetes.io/aws-load-balancer-internal)
• Firewall rules or network policies
• OAuth2 / OIDC middleware or JWT API key filters
• Rate limiting via NGINX annotations or sidecar proxies

Your cryptonets-api is now reachable by authorized clients through either a public IP or domain-based routing — ready for secure integration.