Learn Kerberos - Kerberos in the Cloud

#Introduction

Episode 26 took you to large scale. Episode 27 moves it to the cloud, where virtual networks, managed services, containers, and orchestration change the way you think about the KDC, DNS, and firewalls — the goals stay the same: a KDC that's always reachable, accurate time, and correct DNS.

#AWS: A KDC on EC2

On AWS, the most direct approach is running your own KDC on EC2: launch a Linux instance, install the MIT Kerberos packages, then make it the master KDC plus replicas. Because you have full control over the OS, all the material from previous episodes applies — only the network and DNS are adapted to the VPC.

krb5.conf for a KDC on EC2

[libdefaults]
    default_realm = CLOUD.EXAMPLE.COM
    dns_lookup_kdc = true
    dns_lookup_realm = false
 
[realms]
    CLOUD.EXAMPLE.COM = {
        kdc = kdc1.cluster.local
        admin_server = kdc1.cluster.local
    }
 
[domain_realm]
    .cloud.example.com = CLOUD.EXAMPLE.COM

Note that dns_lookup_kdc is enabled — this lets clients find the KDC via DNS SRV, so you can add or replace KDCs without changing client configuration one by one.

#AWS Security Groups

The firewall on AWS is called a security group. For a KDC, open the specific ports, nothing more:

aws ec2 authorize-security-group-ingress \
    --group-name kdc-sg \
    --protocol udp --port 88 --cidr 10.0.0.0/16
aws ec2 authorize-security-group-ingress \
    --group-name kdc-sg \
    --protocol tcp --port 749 --cidr 10.0.0.0/16

The source CIDR should be restricted to your VPC range, not 0.0.0.0/0. Ideally kadmin is only reachable from an administration host. Port 88 must be open to every subnet that needs authentication.

#AWS Directory Service (Managed AD)

If you don't want to manage the KDC OS yourself, AWS offers AWS Directory Service with two main options:

• Simple AD — Samba-based, enough for basic authentication and compatible with many tools.
• Managed Microsoft AD — an AWS-managed Windows Server directory that supports trust with on-prem AD.

Both options handle replication, patching, and high availability automatically. You no longer manage the KDC directly — though remember, Kerberos administration inside them is tied to the AD model, not the kadmin you've come to know.

#GCP: A KDC on Compute Engine

On GCP the approach is similar: launch a Compute Engine VM, install the MIT Kerberos KDC, and place it in the VPC. What differs is the network details — for example, firewall rules are based on tags, not security groups.

gcloud compute firewall-rules create kdc-allow \
    --allow udp:88,tcp:88,tcp:464,tcp:749 \
    --source-ranges 10.0.0.0/16 \
    --target-tags kdc

#Cloud DNS on GCP

Kerberos clients on GCP can find the KDC via Cloud DNS. Create an A record for each KDC and SRV records for _kerberos._udp and _kerberos._tcp on the internal domain. Since GCP VPCs have built-in internal DNS zones, you just add the records there.

host -t SRV _kerberos._udp.cloud.example.com

If host returns an SRV record pointing to the KDC address, the client can find its realm. This is the same test used in the earlier DNS episodes.

#Azure: Azure AD Domain Services

On Azure, the main choice is Azure AD Domain Services (now part of Microsoft Entra ID Domain Services). This service provides a Windows-compatible managed domain that supports protocols like Kerberos — without building your own domain controller. For full control, the alternative is a Linux VM running an MIT KDC inside the Virtual Network, with Azure DNS as the resolver.

#Hybrid Cloud: Trusting On-Prem to Cloud

Most organizations don't move all at once: they add a cloud realm, then connect it to the on-prem realm via cross-realm trust — the material of episode 10. This trust can be two-way and lets principals from one realm be used in the other.

Adding the cloud realm to on-prem clients

[realms]
    CLOUD.EXAMPLE.COM = {
        kdc = kdc1.cluster.local
        admin_server = kdc1.cluster.local
    }

Once the trust is installed, on-prem users can request service tickets from the cloud, and vice versa — as long as KDC capacity and realm policies support it.

#VPN and Direct Connect

Cross-realm trust in the cloud depends on connectivity. Kerberos traffic can travel over:

• Site-to-site VPN — cheap, quick to set up, suitable for light loads.
• Direct Connect / ExpressRoute / Interconnect — dedicated private connections, stable, suitable for production.

Latency is Kerberos's enemy. Every AS-REQ, TGS-REQ, and AP-REQ round adds several round-trips. If the on-prem KDC and cloud clients are thousands of kilometers apart, every authentication feels slow — the solution is placing KDC replicas near the clients, exactly the principle you learned in episode 26.

#Containers: A Dockerized KDC

Containers change how a KDC is deployed. An MIT Kerberos image can run as an ordinary container, e.g. docker run -p 88:88 -p 88:88/udp kdc:latest. Remember: the principal database and keytabs live on disk, so volumes must be persistent.

#Kubernetes and Service Mesh

On Kubernetes, a KDC is usually deployed as a Deployment with a ReplicaSet, or a StatefulSet when you want stable identity, with a Service exposing ports 88 and 749. Service mesh integration allows Kerberos credentials to be used for mTLS or mapped to mesh identity, so cross-pod authentication stays consistent.

KDC deployment in Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kdc
spec:
  replicas: 2
  selector:
    matchLabels:
      app: kdc
  template:
    metadata:
      labels:
        app: kdc
    spec:
      containers:
        - name: kdc
          image: kdc:latest
          ports:
            - containerPort: 88
            - containerPort: 749
          volumeMounts:
            - name: krb5-db
              mountPath: /var/lib/krb5kdc
      volumes:
        - name: krb5-db
          persistentVolumeClaim:
            claimName: krb5-db-pvc

#Ephemeral Credentials in Containers

The biggest container challenge is credentials: pods are created and destroyed constantly, so a ticket cache on the filesystem can't be relied on. Common patterns:

• Keytab in a secret or volume — a pod grabs a keytab at birth, requests a TGT, then deletes it when done.
• Short tokens — request tickets with a short lifetime just enough for one job.
• Workload identity / projected credentials — the platform injects temporary credentials replaced periodically, so no long-term secret lingers.

#Conclusion

Episode 27 showed that Kerberos isn't a technology that resists modernization. In the cloud you can choose a standalone KDC on EC2, Compute Engine, or an Azure VM; managed services like AWS Directory Service, GCP Managed AD, and Entra ID Domain Services; and connect on-prem to cloud via trust and VPN or Direct Connect — even running KDCs in Docker and Kubernetes.

Key takeaways:

• Network and DNS are the foundation — security groups, firewall rules, and DNS SRV determine whether clients can find and reach the KDC.
• Managed AD sacrifices control — practical, but you no longer hold the kadmin keys.
• Latency determines KDC placement — put replicas near clients, don't let all authentication cross continents.
• Containers need a credential strategy — don't let keytabs and tickets linger in non-persistent pods.

In the next episode, episode 28, we open a new page: modern authentication alternatives — comparing Kerberos with OAuth2 and OIDC, SAML's role in federation, and how everything can coexist in one organization.