As organizations adopt cloud-based infrastructure, application services running in the cloud must be able to establish trusted communication with on-premise systems of record, such as databases and data lakes. While technologies like VPN and secure interconnect may provide a course-grained perimeter around an organization’s cloud services, fine-grained security within that perimeter is typically provided by application-to-application authentication. For many organizations this authentication is provided by Kerberos (and often backed by Active Directory).
Thus, to allow rapid cloud adoption without compromising security, extending existing Kerberos-based authentication to services deployed in the cloud becomes a priority for IT security and engineering teams.
However extending existing Kerberos-based authentication into cloud- and container-based environments is often stymied by the following obstacles:
- Manually provisioned credentials are incompatible with cloud automation: Services that participate in Kerberos authentication must first establish a connection to the Kerberos-enabled Identity Provider (IdP) using a keytab—a long lived credential. Any actor who obtains this credential can impersonate this service, and often do so undetected. In traditional environments, a trusted human operator generates this credential manually and delivers it to the node running the service. However, in cloud-based or container-based environments where nodes and/or services are provisioned dynamically (for example, because of elastic scaling in the public cloud, or dynamic scheduling in a container orchestrator), this process must necessarily be automated. This, in turn, requires complete trust in the automation process as well as the workload itself, and any human operator who interacts with it.
- Long lived credentials become an attractive target: Since keytabs are long lived credentials, they become an attractive target for a malicious actor because they can be used to impersonate a service long after it has been exfiltrated.
- Providing network line-of-sight between an identity provider and cloud service is complex and poses a risk: In traditional Kerberos authentication, a source service requires a network line-of-sight not only to the destination service it is calling but also to the Kerberos identity provider itself (for example, an Active Directory deployment). This can be logistically challenging (given the dynamic nature of cloud networking) and demands that the security team perform additional investigation of the workload and its security privileges, which slows time to delivery.
- Load spikes on the IdP disrupt service performance: In traditional environments, a Kerberos keytab is typically exchanged for a short lived ticket-granting ticket when the service starts or first authenticates, a cryptographically expensive operation. However, provisioning services rapidly through automation, elastic scaling, or dynamic scheduling can lead to unexpected load spikes on the IdP, which can have a widespread impact on services dependent on that provider.
- Limited audibility of the ticket issuance makes compliance difficult: Compliance and security best practices often require detailed auditing of when and where authentication credentials are issued, which entitlements they confer, and for how long credentials are valid. Conventional IdP’s auditing Kerberos ticket issuance typically rely on recording the IP address of the user principal that requested the ticket. In cloud- or container-based deployments, an IP address is not a useful, stable identifier for auditability.
Scytale Enterprise allows you to easily and securely extend Kerberos-based authentication infrastructure to the cloud. The solution securely issues short lived credentials from on-premise identity providers (IdPs) such as Active Directory to dynamic cloud and container-based services. It also enables cloud services to access on-premise services without exposing IdPs to the public internet or breaking or changing existing risk policies. Sign up for a demo here