Workload Identity in Multi System Environments
charter-ietf-wimse-00-00
Document | Proposed charter | Workload Identity in Multi System Environments WG (wimse) Snapshot | |
---|---|---|---|
Title | Workload Identity in Multi System Environments | ||
Last updated | 2024-01-31 | ||
State | Start Chartering/Rechartering (Internal Steering Group/IAB Review) Rechartering | ||
WG | State | BOF | |
IESG | Responsible AD | Murray Kucherawy | |
Charter edit AD | (None) | ||
Send notices to | (None) |
Background & Motivation
The rise of diverse service platforms and the drive for business flexibility, cost-efficiency, resilience, and compliance make maintaining least privilege access for workloads increasingly complex. As a result of the adoption of micro-service architectures, services are composed of multiple workloads that need to authenticate to each other while making authorization decisions based on the original caller, their context, and the actions of other workloads that acted on a transaction. These workloads are often distributed across trust boundaries, without a single centralized controller managing the different identities or authorization policies.
While several standards and open-source projects offer foundational elements for secure workload identity, there remains a lack of clarity in their interoperation and combination. These technologies (specifically: OAuth, JWT and SPIFFE) have been combined in a variety of ways in practice, but the solutions have existed in relative isolation. This ambiguity can lead to inconsistencies, interoperability issues, and potential security vulnerabilities.
Scope
The Workload Identity in Multi-Service Environments (WIMSE) working group is chartered to address the challenges associated with implementing fine-grained, least privilege access control for workloads deployed across multiple service platforms, spanning both public and private clouds. The work will leverage existing standards, open source projects, and community practices, focusing on combining them in a coherent manner to address multi-service workload identity use cases such as those identified in the Workload Identity Use Cases (draft-gilman-wimse-use-cases) I-D.
Goals
The goal of the WIMSE working group is to identify, articulate, and bridge the gaps and ambiguities in workload identity problems and define solutions across a diverse set of platforms and deployments. The WIMSE working group will consider both HTTP and non-HTTP protocols (such as GraphQL, gRPC and Kafka), though initial deliverables will focus on specific REST-based technologies.
The WIMSE working group aims to address the following major considerations through near-term and long-term deliverables:
-
Establish Best Current Practices (BCPs): Define guidelines on effectively combining existing standards from different ecosystems to cater to various workload identity scenarios.
-
Identify and Advocate for Gap-filling Work: Engage with other relevant working groups to pinpoint and address gaps in current standards. This will involve thorough collaboration, ensuring that emerging standards are consistent, holistic, and interoperable.
-
Standardize New Solutions: If gaps cannot be addressed within other working groups, initiate and develop new standards that provide the needed functionality and ensure their widespread adoption.
Workloads are often associated with complex context, including user identity, software origin and hardware-based attestation. Communicating this context involves a unique set of challenges across different scenarios including multi-hop, long-lived and asynchronous transactions. WIMSE will consider this context in authorization decisions, record keeping and auditing solutions, and wire formats and protocols between elements of a workload, both within and across security boundaries.
Dependencies and Liaisons
The WIMSE working group will closely collaborate with:
-
Other IETF working groups that address topics related to identity, authentication, and authorization, including, but not limited to, OAuth, SCIM, and RATS.
-
The Cloud Native Computing Foundation (CNCF), particularly with regard to the SPIFFE/SPIRE project.
-
The OpenID Foundation and other organizations working on similar standards.
Initial Deliverables
Please note that the order of items does not reflect their priority or expected delivery order.
-
WIMSE architecture: The group will develop an Informational document that defines common terminology, discusses workload attestation and identity, and specifies a threat model. The WIMSE architecture will be drawn from experience with other working group documents and is not intended as a prerequisite for their completion. The document will describe 2-3 scenarios and for each of them, it will identify existing standards and gaps where a new standard (or a profile) is needed for interoperability. The document’s goals and format are inspired by the RATS architecture, RFC 9334.
-
Securing service-to-service traffic: a JOSE-based token solution for service authn/authz to protect a chain of HTTP/REST calls, within and across trust domains. The document should support strong identification of microservices and cryptographic binding of the token to the caller’s identity and optionally, binding to the transaction. It should support associating arbitrary context with the token, including but not limited to user identity, platform attestation and SBOM artifacts. Context may also include authorization information, however defining the semantics of such information is out of scope. This deliverable includes both a token format and usage, including binding to the caller’s identity.
-
Token issuance: A document describing a method for issuance of tokens within a workload component. In addition to generic token issuance, the deliverable will describe local token issuance where the issuer operates with limited authority in order to reduce risk, improve latency and enhance reliability.
-
Token exchange: A document describing a method for exchanging an incoming token for a workload-specific token at security boundaries in the context of workload identities (possibly based on RFC 8693). It will include a small set of token exchange profiles (mapping of claims) that enable authorization in call chains, in addition to interoperable access from SPIFFE-identified services to OAuth-protected resources and vice versa.
-
Document existing local token distribution practices for workloads: An Informational deliverable describing the considerations and best practices for filesystem-based token delivery in Kubernetes. A proposed starting point is draft-hofmann-wimse-workload-identity-bcp-00.