devopsy.kinsta.cloud

Tag: SPIRE

  • Introduction to SPIFFE/SPIRE

    Introduction to SPIFFE/SPIRE

    For a long time, people have been logging into the apps they use via passwords or password managers. And many open standards and identity providers on the market continue to evolve how users authenticate and authorize with websites and applications. The issue is that the same problem exists for software services—when applications talk to applications, how do we prove the credibility of service-to-service connections?

    Enter SPIFFE and SPIRE. SPIFFE is a specification for implementing identity for workloads, and SPIRE is the code that implements this specification in practice. Together, the projects create a standardized, secure way to identify software services and authenticate them. SPIFFE and SPIRE recently reached graduation status with the Cloud Native Computing Foundation (CNCF), solidifying the projects’ maturity as a top open-source standard mechanism to deliver cryptographic runtime identity for both cloud-native and legacy workloads.

    SPIFFE and SPIRE are already used across many major public deployments. Yet not all developers are familiar with their intricacies. Below, I’ll take a gander at both projects and how they operate to provide a bit more context. I also spoke with Evan Gilman, SPIFFE/SPIRE maintainer, to gather more insights on the history of the projects and their future goalposts.

    What is SPIFFE?

    The Secure Production Identity Framework For Everyone (SPIFFE) is a specification for workload identity. According to Gilman, the easiest way to think about SPIFFE is as a passport. Similar to how people are issued passports in a common shape with a barcode and standard information, SPIFFE dictates the standard methods to prove and validate the identity of a service. It’s like bringing the “Sign in with Google” experience to the software services themselves, he adds.

    There are three key components in SPIFFE. First, SPIFFE specifies that services shall identify themselves with what’s called a SPIFFE ID, which is defined as a URI in the format of spiffe://trust-domain-name/path. These IDs are then encoded into a SPIFFE Verifiable Identity Document or SVID. SVIDs aren’t so much a document type themselves — instead, they support either X.509 or JWT document types. Last but not least, SPIFFE specifies a workload API that issues and rotates these SVIDs, along with the keys needed to validate them.

    What is SPIRE?

    SPIRE is the code that implements the SPIFFE specification—you can think of it as a production-ready SPIFFE runtime environment. SPIRE, the “flagship SPIFFE implementation,” is a true end-to-end instantiation of SPIFFE that securely issues SVIDs, renews SVIDS and performs attestation, among other functions. If SPIFFE defines what a passport is, then SPIRE is the agency that issues the passports, said Gilman.

    The SPIRE agent runs on a node and exposes the workload API, which hooks into each workload. A workload, as defined by the SPIFFE documentation can be a web server, an instance of a MySQL database, a worker program or a web application composed of independently deployed systems. By communicating in this manner, SPIFFE/SPIRE can solve the issue of “secret zero,” which refers to the conundrum of proving the first credential to newfound systems.

    More Background on SPIFFE/SPIRE

    Joe Beda, a co-founder of Kubernetes, first proposed SPIFFE at GlueCon in 2016. At the time, Google was considering what internal technology it had that might prove helpful to the broader industry. It’s said that the technology that inspired SPIFFE/SPIRE can trace its roots to security and identity subsystems brought to Google from AT&T and Bell Labs.

    Nowadays, SPIFFE/SPIRE is actively maintained by many organizations, and we continue to see impressive production use cases. “SPIRE is deployed in some staggeringly large cases,” explained Gilman. SPIFFE/SPIRE adoption can be seen within GitHub, Netflix, Pinterest, Square, Transferwise, Uber and many other large technology companies. In terms of ownership, Gilman said that SPIRE is most used by platform engineers, infrastructure engineers or security engineers, depending on the organization’s roles.

    Future Outlook for SPIFFE and SPIRE

    SPIFFE/SPIRE appear to have the resources and backing to maintain a stable implementation, so the future looks bright for both projects. In terms of new features, in mid-2022, a first-class integration with SPIRE was merged into the Istio service mesh as a more flexible alternative to Istio’s built-in SPIFFE implementation. Another recent update is experimental support for SPIRE on Windows. Regarding future plans, SPIFFE/SPIRE maintainers will likely continue to iteratively improve the specification and implementation with frequent updates.

  • SPIRE Now Runs on Windows!

    At its heart, the SPIRE project aims to solve the problem of securely issuing workload identities at scale, no matter where the workload is running. It does that by having an extensible architecture composed of plugins that allow SPIRE to grow depending on the needs of supporting different platforms, cloud providers, etc. Until now, SPIRE could only be deployed on Linux platforms. But that is now a thing of the past with the new experimental Windows support in SPIRE 1.3.0!

    What kind of support is being introduced?

    Over the years, SPIRE, a production-ready implementation of the SPIFFE standards, has gained a high degree of maturity on Linux platforms. We have learned a lot in terms of how SPIRE is deployed, operated, and integrated into a variety of Linux environments.

    Windows support is being introduced incrementally as an experimental feature. We anticipate that as our operational experience with Windows evolves, changes that impact the user experience or functionality will need to be introduced. We will be working hard to fill the gaps and stabilize Windows support over the next several SPIRE releases.

    The 1.3.0 release adds support for running both the SPIRE Server and Agent on Windows. Existing plugins have been adapted to work under Windows, where applicable. In addition, a new Windows-specific workload attestor has been added (similar to the existing Unix workload attestor) for providing Windows-specific attributes to Windows workloads.

    What’s the difference?

    One guiding principle of the SPIRE project is to strive for ease-of-use and intuitive configuration. With that in mind, running SPIRE on Windows feels very similar to running it on Linux. Configuration differences are limited to areas where platform specific features are in use (e.g. Unix Domain Sockets, named pipes, etc).

    The work that we have ahead

    Supporting SPIRE on an additional operating system is not a trivial task. As we pointed out, SPIRE has been growing in maturity and stability on Linux platforms over several years. We know that we will need to work across several releases to provide a similar level of feature parity with what we have today on Linux platforms. We have a lot of work ahead in multiple dimensions:

    • The SPIFFE Workload Endpoint standard does not yet support exposing the Workload API as a named pipe endpoint. We will be working closely with the SPIFFE SIG Spec group to update the specification to standardize the way that SPIFFE implementers (like SPIRE) can use named pipes to serve and consume the Workload API.
    • The K8s workload attestor plugin is not yet supported on Windows due to a difference in support for key K8s features that we rely on to attest K8s-based workloads. We are actively investigating alternative means to attest Windows workloads running in K8s.
    • While the go-spiffe library has been updated to support the use of named pipes with the Workload API, other language libraries have not. This is in part due to a lack of support for named pipe transports in the C/C++ gRPC library. We have work to do to provide this support, which may include collaborating with others in the ecosystem to develop and upstream requisite changes to libraries like gRPC.

    We want to hear from you

    Though support for Windows is very new, we’ve collaborated with interested community members to design and verify the current feature set. SPIRE is already running in test environments, with plans to deploy to thousands of Windows hosts. This early adoption has been and will continue to be integral to stabilizing our support. We are very eager to learn more from the community and early adopters how we can better support providing secure service identity to workloads running in Windows environments.

    If you have requests or anything to say about this new support, we want to hear! Please don’t hesitate to open an issue in the GitHub repository asking for a feature or to report a bug. Also, you can join the awesome SPIFFE community on Slack: https://slack.spiffe.io/. We will be happy to answer your questions and discuss your requests. Lastly, if you want to be up to date on all the news for the project, join the SPIFFE Announce mailing group, which is a low frequency list of project announcements: https://groups.google.com/a/spiffe.io/g/announce.

  • CNCF Elevates SPIFFE Spec to Secure App Services

    CNCF Elevates SPIFFE Spec to Secure App Services

    The Technical Oversight Committee (TOC) of the Cloud Native Computing Foundation (CNCF) announced that the open source Secure Production Identity Framework For Everyone (SPIFFE) specification and the SPIFFE Runtime Environment (SPIRE) have become incubation-level hosted projects.

    Andrew Harding, SPIRE maintainer and a principal software engineer at Hewlett Packard Enterprise (HPE), said the elevation of a potential standard to authenticate software services using cryptographic identities that are platform-agnostic could go a long way toward advancing the adoption of best DevSecOps practices.

    At the core of SPIFFE specification are short-lived cryptographic identity documents known as SVIDs that are invoked via an application programming interface (API). Workloads employ an SVID when authenticating to other workloads by establishing a TLS connection or by signing and verifying a JSON web token (JWT).

    Previously a sandbox level project, the SPIFFE specification is designed to reduce reliance on hard-coded secrets to authenticate application services, Harding said. Instead, developers will be able to more easily invoke multi-factor authentication to issue and verify identities for any type of application service. Each service is given its own identity, he noted.

    Amazon, Bloomberg, Google, HPE, Pinterest, Square, TransferWise and Uber are all contributors to SPIFFE. Since joining the CNCF last year contributors to SPIRE have added support for Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure, Kubernetes and bare-metal servers.

    SPIFFE and SPIRE are designed to work across both monolithic and microservices-based applications. The latter are not likely to completely replace the former anytime soon, so IT organizations need a consistent approach to authentication regardless of how an application is built, noted Harding. SPIFFE and SPIRE together enable an IT organization to implement a zero-trust architecture spanning multiple applications, he said.

    Ultimately, Harding said the goal is to enable better application security without compromising flexibility. As an added benefit, SPIFFE and SPIRE don’t require developers to share application secrets to enable interoperability between services running on different platforms. That’s because SPIRE doesn’t generate SPIFFE identities that can be used to authenticate to other systems nor does it store existing keys such as a database password on behalf of a workload. Each SVID generated is unique to the service use case.

    As the number of services and platforms being employed continues to increase, it’s not practical to continue to rely on approaches to authentication that rely on hard coding. The level of dependency that exists between services requires a more frictionless approach to authentication.

    It may be a very long time before reliance on tokens such as passwords disappear. However, it’s clear specifications such as SPIFFE, in the long run, will transform application security. The challenge now is not only getting developers to appreciate a new approach but also convincing skeptical cybersecurity teams that long have relied on some form of hard or soft token to secure applications. Given the number of times those tokens are misplaced or lost, there are more than a few IT help desk professionals wishing tokens would become obsolete sooner than later.