20 years ago, “service authentication” was a relatively simple proposition for enterprise security teams. First, enterprises typically only had a few services to manage within their own datacenters. Second, these services usually executed on a relatively small and stable set of interconnected physical machines.
Modern enterprise software architectures are nowhere as simple. Customer-facing services rely upon a myriad of interdependent internal software services that are managed by different teams in different lines of business, and running on widely divergent technology stacks.
Not only has there been a recent explosion in the number of services, but the environments in which these services operate are more complex than ever before. Technologies like cloud computing allow faster releases of more resource-efficient applications and services, but they have also forced enterprises to evolve towards more complex security models to protect existing on-premise services and new cloud-based services.
Containers and functions add complexity to this already challenging landscape. Services are now not only elastically scaled but also dynamically scheduled and ephemeral — moving from machine to machine at a moment’s notice. Static network identifiers like IPv4 or IPv6 addresses are largely meaningless in this world from an authentication perspective — requiring once again a shift in how services built on these technologies can be secured alongside existing systems.
The confluence of these trends — microservices, cloud, and containers — creates substantial new challenges for security teams. Network perimeters, established by firewall rules, are insufficiently dynamic to be able to isolate and protect inter-service communication in such a heterogeneous environment.
In many cases, even coarse-grained network protection is insufficient as enterprises seek to mix highly trusted services (such as PCI-certified payment systems) on the same platforms as less trusted systems (such as those developed by contractors). It is increasingly becoming necessary to assume that even the internal network is, to some extent, hostile.
For organisations seeking to rely less on the network — they must instead rely on services themselves to establish trust between each other — and to be able to encrypt traffic between each other. This is the premise of “zero trust” networking. And zero trust networking relies on strong authentication between services core to establish trust.
Re-thinking service authentication for a zero-trust world
While identity and authentication standards — such as Kerberos and oAuth — do exist today and are widely employed, they are generally unsuitable as the foundation of a scalable zero-trust network. In 2017 we recognized that for a service identity framework to supporting zero-trust it would need to embody 10 key characteristics:
- Support both identity and confidentiality. Users should be able to use the system to guarantee both identity of a service as well as and the integrity and privacy of communication to it. Modern proven cryptographic systems should be leveraged to verify the identity of both source and destination.
- Be cloud- and container- friendly. The framework should work well in elastically scaled cloud environments, and dynamically orchestrated containerized environments, as well as environments that are neither.
- Be easy to use. Installing or correctly using the framework shouldn’t require deep knowledge of topics like cryptography or public key infrastructure. It should be possible to use the framework to secure existing systems with little or no code change.
- Support “multi-factor” identity. Instead of using hard-to-secure techniques like an API key or username and password, trusted third parties like orchestrators, CI/CD pipelines, cloud platform control planes, and secure enclaves should be used in concert to establish the identity of a service uniquely in any environment. This has an advantage too that a service does not need to be made aware of its own identity is before it is deployed.
- Be reliable at scale. To be reliable at scale — particularly for cloud-hosted services — any identity must be able to operate smoothly even when parts of the system are subject to a failure. Two services should be able to authenticate successfully even if other supporting services (such as a centralized identity server) are temporarily unavailable.
- Work across varying authentication use-cases. While often authentication is thought of in the context of authenticating an HTTP API call, “authentication” also applies to many other use-cases such as securing a TCP stream, or signing a message on a queue. An identity framework should support these use-cases.
- Separate the concerns of development and operations teams. Delivery of a service into production (including configuring how that application authenticates to another) requires deep cooperation between the development teams that build the software and the operations teams that are responsible for securing, deploying and maintaining those services. By standardising on an API between a service and its operating environment for authentication, this cooperation can be greatly simplified.
- Quarantine privileged knowledge. A compromised machine should never ever compromise any secrets for services running elsewhere.
- Be federate-able. It should be possible to use identities to establish trust across and between enterprises or business units that don’t share common IT systems.
- Be fully autonomous. In an enterprise IT environment that’s both ephemeral and dynamic, establishing trust must be policy-driven, automated, and audit-able.
SPIFFE and SPIRE, the open-source foundation for service identity
Inspired by these principles, as well as building on the established patterns from organisations such as Google, Facebook, and Netflix, Scytale and others together developed the open-source SPIRE project and SPIFFE standard. These projects, now under the auspices of the Cloud Native Computing Foundation (CNCF), allow organisations of all stripes to easily implement best practices for service authentication in a wide range of operating environments.
Specifically, the projects’ goals are to ensure that any service, running anywhere, can retrieve a short-lived, cryptographically verifiable identity, either as a JWT bearer token or as an X.509 key and certificate.
We’ve been thrilled with the interest and growing gravity around these projects since their 2017 launch. In 2019 alone, we’ve seen significant project contributions from Square, Uber, and several others.
Just as importantly, we’ve begun seeing a growing community of open-source projects align around SPIFFE. Integrations now exist for Envoy, OpenTracing, nginx, Istio, Knox, and Ghostunnel, with more on the way.
As SPIFFE and SPIRE continue to grow and evolve under the auspices of the CNCF and a growing set of contributors, Scytale continues to serve as a key contributor and steward of the projects.
RSA 2019: bringing service identity management to the cloud-native enterprise
Scytale’s work doesn’t stop with SPIFFE. Since 2017, we’ve engaged with 100+ enterprises (including several Fortune 100s) about their emerging challenges for service authentication as multi-cloud and containers become an inevitable part of their IT roadmap.
These organisations recognize the enormous opportunity to use SPIFFE and SPIRE to standardize their identity model across multiple cloud, container, and on-premise deployments. But, they also emphasized the importance of reconciling this with existing (and mission-critical) investments in identity and entitlements.
We’ve been hard at work solving these challenges and are showing a sneak peek next week of our commercial offering at the RSA conference in San Francisco. If you’re attending the conference, stop by startup booth 103 or join us at our mixer on Monday night to learn more and meet us! And whether you’re in town or not, follow us at @scytale_io to learn where we’re going next.