Hello Fedora community!
I’d like to explore if SPIFFE can serve as an alternative foundation for subscription-manager, which provides authentication to protected RPM repositories. The current server authentication mechanism is based on Candlepin and relies on mTLS certificates. Candlepin was designed for a world of single-tenant servers/VMs and worked around capabilities that were missing in content delivery networks. It is not well suited for multi-tenant container orchestration platforms like Kubernetes. Among the challenges:
- Entitlement certificates are designed to be long-lived, and there is no pre-defined expiration for these certificate keys. Leaked entitlement keys may be considered an information security risk for RPM repositories that distribute private/proprietary code.
- Certificate keys encode all of the repositories that the subscribed system has access to. This co-mingles authentication and authorization concerns, resulting in relatively large files being written to disk.
- Podman provides special symlinks to containers so that container workloads can access entitlement information on the host (ex: during a buildah container build). This mechanism de facto forces workloads to be “subscribed” to the same “system” as the host. In the past, build workloads that needed entitlements on non-subscribed hosts needed to “trick” subscription-manager by removing these special symlinks. This requirement was eventually removed.
- Kubernetes assumes nodes are ephemeral, and Kubernetes-optimized distributions like RHEL CoreOS do not include subscription-manager.
- Distributing “cluster-scoped” entitlement keys in Kubernetes is limited by the size limits of Kubernetes objects (1MB maximum).
I can go into the details of the ugly work-around that was implemented for OpenShift, however I doubt that will be of much interest to the Fedora community.
Proposed Alternative - SPIFFE/SPIRE
Using the SPIFFE standard, the current hard “system identity” is replaced with the more flexible “workload identity” concept. Workloads register to a trust domain and can receive a SPIFFE Verifiable Identity Document (SVID) upon request. A single Fedora instance can serve both as a workload ID and a trust domain for individual processes (like containers!) through a deployed SPIRE agent, which registers with a respective SPIRE server.
A federated identity provider that supports SPIFFE, such as Keycloak, can exchange SVIDs for short-lived access tokens. Registered systems on the “other side” of the identity provider, like RPM repository hosts, use these access tokens to perform authorization. In this architecture:
- SPIRE agents fill in the role of subscription-manager for DNF.
- SPIRE servers fill in the role of Candlepin servers for workload registration.
- Identity providers mediate authentication between SPIFFE-attested workloads and RPM repositories (or any other registered “downstream” system).
I see this approach having several advantages:
- Access tokens are ephemeral and short-lived, reducing information security risks of a leaked token.
- SVIDs are small and scoped only to prove identity (not access).
- Multitenancy can be supported through SVID attributes that are expressed through implementing SVID standards, such as JWT-SVID and X509-SVID. This allows the identity of the workload to be distinguished from the host system.
- SPIRE provides a consistent mechanism for workload attestation that supports regular Linux processes, Podman containers, and Kubernetes pods.
Many systems support federated identity today, including Pulp v3 and container registries. Leveraging identity providers that support SPIFFE can future-proof RPM repository access to other ideas in the community, such as using OCI artifacts to distribute RPM repositories.
Some of this probably feels hand-wavy, and frankly I am not an expert on deploying SPIFFE/SPIRE in production. I welcome any feedback or concerns with this idea. Please share your thoughts on how this could impact the Fedora project and community at large. Thanks!