Session Date/Time: 07 Nov 2023 12:00

wimse

Summary

This "Birds of a Feather" (BoF) session explored the potential for IETF work on workload identity in multi-tenant environments (WIMSE). The session included presentations on use cases, existing technologies like SPIFFE, and proposed solutions. A key focus was on identifying gaps in current standards and exploring potential new work items. The discussion highlighted the need for a well-defined scope to prevent the BoF from becoming an unfocused collection of disparate ideas. The group took a poll about interest in the topic and contributing to the draft. There was not a clear consensus as to whether this effort should be AR or SEC area.

Key Discussion Points

The Challenge: Customers struggle to manage workload identities and implement zero-trust architectures across multiple cloud and service environments due to a lack of standardized identity systems.
Leveraging Existing Standards: While many relevant standards and community projects (SPIFFE, MTLS, OAuth, OpenID Connect, RATS, Cedar) exist, gaps remain in connecting these ecosystems for workload identity.
Request Binding: Challenges exist in securely retaining the original identity as requests are passed between workloads within a compute environment. Existing mechanisms like Depop do not fully cover the relevant threat model.
Workload Definition: Clear discussion that a workload is a specific piece of software fulfilling a particular purpose and may involve multiple copies of the same software.
Use Cases: Various use cases were presented including constrained credential security, cross-workload access, chain of custody of requests, localized authentication and authorization decisions, disconnected audit logs, and general requirements around observability and manageability.
SPIFFE: SPIFFE (Secure Production Identity Framework For Everyone) is a workload identity specification living in the CNCF, widely adopted for workload-to-workload authentication and identity. It does not however create new token types.
Container Technologies: Container technologies like Kubernetes and Docker employ specific mechanisms (e.g., "service account volume projection") for workload identity. Standardizing the usage and configuration of these mechanisms could improve interoperability.
Token Containers: A token container approach, treating the request as a graph rather than a linear flow, was proposed to accommodate multiple statements from different systems along the request path.
Transparency Services: Transparency logs, which are often found in supply chain contexts, can be used to further improve the security of nested token flows.
Charter Scope: Concern was raised that the proposed charter was too open-ended, potentially attracting irrelevant or previously rejected work. It was proposed that the charter be more tightly focused on specific initial work items.

Decisions and Action Items

Action Item: Refine the charter to have a much more limited scope and list the specific deliverables, rather than being generally focused on all workload identity.
Action Item: Prioritize initial efforts on documenting existing architectures and developing best practices using existing technologies.
Action Item: Revisit the need for new standards work based on identified gaps, after a period of analysis and documentation.

Next Steps

Continue discussions on the mailing list to refine the charter scope and initial work items.
Clarify the proposed architecture document's objective, focusing on documenting current deployment practices of technologies like Kubernetes and Docker.
Consider whether the initial focus should be on existing protocols vs. developing new mechanisms, which will help guide what IETF area is the most relevant.