In the cloud-native computing era, workload identity needs to ensure that identities are secure and trustworthy. In a cloud-native environment, workloads have faster lifecycle activities, and move between different hosts, which makes it difficult to establish and maintain identities. Additionally, traditional IAM (identity and access management) solutions are not designed to handle the dynamic nature of cloud-native workloads. This article explains how to address the challenge with a platform agnostic workload identity framework.
By Hans Emmanuel Nedumthakady, Chief Solution Architect, Cloud Native Computing Practice, HPE Services
With software components distributed across heterogeneous platforms that have dynamic and elastic characteristics, traditional perimeter defence is impractical. This is particularly true in dynamic cloud-native environments where IP and port-based network ACLs are not feasible. In this context, authentication and fine-grained authorization of workloads in multi-cloud and cloud-native environments are among the main challenges faced by organizations.
Identity based Authentication and Authorization of workload is critical for that. Workload identity is a concept that provides a unique identity for workloads. It refers to the secure and reliable identity assigned to a specific workload, such as a container, pod, or virtual machine, in a cloud environment. It is important to have a cryptographic identity which is secure and trustable for workload authentication. Workload identity allows for granular access control, improved auditing, and easier policy enforcement.
One of the main challenges of workload identity is ensuring that identities are secure and trustworthy. In a cloud-native environment, workloads have faster lifecycle activities, and move between different hosts, which makes it difficult to establish and maintain identities. Additionally, traditional IAM (identity and access management) solutions are not designed to handle the dynamic nature of cloud-native workloads.
WHAT ARE SPIFFE AND SPIRE?
These conceptsโidentities, secret management, and authorizationโare all interconnected. When it comes to authorization or access control, a trustworthy identity is necessary. Conventionally, identity can take the form of a secret, a token, or a password. Another secret may be required to protect these secrets in a secret manager. Protecting that secret requires protecting a secret below it and so on. This creates an infinite regress, which is often referred to as โturtles all the way down.โ In this context, finding the ultimate โbottom turtleโ is the principle upon which SPIFFE is built.
SPIFFE stands for Secure Production Identity Framework for Everyone. As per the official SPIFFE Overview doc, โSPIFFE is a set of open-source standards for securely identifying software systems in dynamic and heterogeneous environments.โ The initial goals of solving the workload identity problem were to establish an open specification and corresponding production implementation. So SPIFFE is the specification and SPIRE (SPIFE runtime environment) is the production implementation of SPIFFE. SPIFFE and SPIRE are now graduate projects of the Cloud Native Computing Foundation.
SPIFFE HISTORY
The history of SPIFFE can be traced back to 2016 when a group of engineers from various companies, including Google, Netflix, and Cisco, came together to discuss the challenges they faced in securing service-to-service communication. They recognized that traditional authentication mechanisms like username-password pairs and perimeter defence were not suitable for dynamic and highly distributed environments.
In response to these challenges, the engineers created the SPIFFE project with the goal of developing a standardized framework for providing cryptographic identities to workloads in a platform-agnostic way. The project was open-sourced from the beginning, with the belief that a collaborative effort and community involvement would be crucial to its success. In 2020 the Cloud Native Computing Foundation (CNCF) accepted SPIFFE and SPIRE as incubation-level hosted projects and in 2022 they became CNCF-graduated.
SPIRE components
SPIRE Server
A SPIRE Server is responsible for managing and issuing all identities in its configured SPIFFE trust domain. It will store the registration entries for workloads and agents to the selected datastore. Depending on the selectors associated with a registration entry, it decides the SPIFFE ID and issues SVID with that SPIFFE ID. The server issues SVID for workloads via agents, where workloads will request identity to agents via an agent workload API.
SPIRE comes with many plugins for different functions. Some of those plugins are shown below.
Node attestor plugins verify the identity of the node where the agent is running through agent node attestors.
Node resolver plugin. This expands the set of selectors that the server can use to identify the node by verifying additional properties about it.
Datastore plugin. The server component of this system relies on a datastore plugin to enable the storage, querying, and updating of diverse pieces of information. These include registration entries, which indicate nodes that have attested, and the corresponding selectors for those nodes.
The system is designed to work with a variety of databases, including MySQL, PostgresSQL, and SQLite 3.
Key manager plugins. The server's storage of private keys is a crucial aspect in the signing of X.509-SVIDs and JWT-SVIDs. In addition, it is important to consider the security of the storage solution, as any breach of the storage can lead to unauthorized access and potential loss of sensitive data. Therefore, it is critical to carefully evaluate and implement appropriate measures to ensure the secure storage of private keys.
Upstream authority plugins. By default, the SPIRE Server acts as its own certificate authority, which means that it generates and signs its own certificates. While this setup is secure and efficient, there may be scenarios where you need to use a different CA from a different Public Key Infrastructure (PKI) system. Fortunately, the SPIRE Server offers a solution to this problem in the form of an upstream authority plugin. This plugin allows you to use an external CA to sign the SPIRE Server's certificates, thereby enabling you to leverage the security and trust of an existing PKI system.
Customizing the behaviour of the SPIRE Server is easy and straightforward. You can do this by configuring plugins and various other configuration variables. Sometimes you may need to modify the server's default behaviour or add new functionality; SPIRE is built with keeping that flexibility in mind.
SPIRE Agent
A SPIRE Agent is a software component that runs on every node where a workload is identified. Its main functions include:
- Requesting SVIDs from the server and caching them until a workload requests it. This caching mechanism is designed to optimize the performance of the SPIFFE authentication process by reducing the number of requests to the server for SVIDs.
- Exposing the SPIFFE Workload API to workloads on the node. When a workload calls this API, the SPIRE Agent attests its identity depending on the selectors and additional workload attributes it collects.
- Agent provides x509 certificate or token for workload API which contains the identity (SPIFFE ID) of the workload.
Overall, the SPIRE Agent plays a critical role in ensuring that workloads are properly authenticated within the SPIFFE ecosystem. Its caching capabilities and support for the SPIFFE Workload API enable efficient and secure communication between workloads. x509 SVIDs of workloads can be used for workload-to-workload mTLS authentication.
Strong cryptographic identity for workloads with SPIFFE & SPIRE
SPIFFE and SPIRE issue strong cryptographic identities for the workloads irrespective of their runtime platform. We say it is strong because SPIRE is not simply issuing the cryptographic identities; rather, it is depending on a multi-factor attestation process to ensure the identity of the workload and the node on which the workload is running.
For business leaders who are looking to improve their business efficiency and increase their returns on investment, SPIFFE and SPIRE can significantly reduce the costs associated with managing and issuing cryptographic identity documents such as x509 certificates. This can lead to a more cost-effective solution for businesses and can help accelerate their development and deployment processes by removing the need for developers to understand the identity and authentication technologies required to secure service-to-service communication.
HPE and SPIFFE & SPIRE
Hewlett Packard Enterprise is the leading contributor to the Cloud Native Computing Foundationโs SPIFFE and SPIRE open source projects. HPE was the core contributor for the istio and SPIRE integration, which makes istio service mesh SPIFFE compatible where SPIRE issues the cryptographic identities for the workloads participating in istio service mesh. This adds more security and capability for adding more context to the SPIFFE-ID of the workloads.
HPE and SPIFFE SPIRE are related in the sense that we may leverage SPIFFE SPIRE as part of our identity management solutions portfolio, providing expertise and support to organizations implementing secure distributed systems based on the SPIFFE specifications. A very basic use case of SPIFFE and SPIRE is to provide identity via x509 certificates to the workloads running across different platforms, which can be used for mutual authentication (mTLS) between the services.
Organizations may need good planning when they are introducing SPIFFE and SPIRE as their workload identity provider, especially in cases where their workloads are running in multiple clouds and in different platforms as virtual machines and containers. HPE Advisory and Professional Services can provide a wide range of services related to SPIFFE SPIRE. Some of these services includes deployment of SPIRE; integration with Kubernetes and istio; integration with cloud providers like AWS, Google cloud and Azure; and custom integration logic with virtual machine provisioning on platforms like OpenStack.
As the use cases are increasing with SPIFFE and SPIRE, we understand that there is a growing need for secure identity management solutions based on the SPIFFE framework, and we are here to help organizations implement these solutions. Our team of experts has a wealth of knowledge and experience in various security domains, including the SPIFFE and SPIRE-based identity framework. We can also provide guidance on best practices for implementing SPIFFE SPIRE.
Services Experts
Hewlett Packard Enterprise
twitter.com/HPE_Services
linkedin.com/showcase/hpe-services/
hpe.com/services
ServicesExperts
HPE Services Team experts share their insights on the topics and technologies that matter most for your business.
