Outcome Overview

Zero-Trust is a necessary paradigm for enterprise customers looking to broaden their footprint across multiple cloud environments. A key tenet of Zero-trust is to "Always Verify, Never Trust". SPIFFE/SPIRE is an identity solution for workloads that not only provides short lived cryptographically signed identities to the workloads but also ensures attestation of the workloads to verify they are who they claim to be.

By providing SPIFFE/SPIRE on OpenShift, organizations can benefit from securing access for applications across clusters    

Success Criteria

What is the success criteria for this strategic outcome?  Avoid listing Features or Initiatives and instead describe "what must be true" for the outcome to be considered delivered.

• SPIRE deployed in OpenShift clusters to provide identities to workloads 
• SPIRE deployed with spiffe-csi driver for mounting workload identity tokens into pods 
• SPIRE deployed in OpenShift Virtualization to provide identities to VM and Containers 
• SPIRE deployed with ACM for multi-cluster workloads on-prem and inclouds
• SPIRE integrated with OpenShift Service Mesh for service authentication 
• SPIRE integrated with Sigstore for build system identity and authentication in TSSC
• SPIRE integrated with Kubelet image credential operator for authenticating to Quay registry with short-lived tokens from SPIRE 

Questions: 

1. How will SPIRE be installed?  A Sample deployment with OpenShift has been done and similar format will be followed see https://next.redhat.com/2024/06/27/spiffe-spire-on-red-hat-openshift/  
   1. SPIRE Server and SPIRE Controller Manager(which will be deployed in the same pod as the SPIRE Server. ) needs to be installed in a separate cluster (Hub) that has network access to the Workload clusters. This is because we want to keep the signing material secure and generally away from the clusters where Workloads are, so in the datacenter/cloud in a secure subnet with proper network-firewalled access. SPIRE Server will be deployed with OIDC plugin and will also have the Tornjak plugin enabled for user management and UI.  
   2. SPIRE agent will be a daemonset that is deployed on every node. Spire CSI Driver will enable mounting Workload API into pods via ephemeral volumes. 
2. How can we ensure system namespaces are not used? Controller manager lets you omit namespaces you dont want monitored. For e.g:  you can ignoreNamespaces: - kube-system - kube-public - local-path-storage - openshift-.* More details https://github.com/spiffe/helm-charts-hardened/blob/main/charts/spire/charts/spire-server/templates/controller-manager-configmap.yaml#L76 
3. SPIRE is meant to provide identities to ONLY WORKLOADS, not the Control Plane Services. 
4. In HyperShift, the Operator should only be deployed in Hosted Clusters and tuned according to the Federation setup.
5. Is Service Mesh needed for SPIRE deployment - No it is not needed but SPIRE can work with Service Mesh. 
6. How does it compare with other tools such as Service Meshes, Identity Providers Secret Stores https://spiffe.io/docs/latest/spire-about/comparisons/ 
7. Has anyone used SPIRE in production? Uber has used this at scale https://www.uber.com/blog/our-journey-adopting-spiffe-spire/ 
8. Is SPIRE going to replace any of the existing workload identity solutions for ROSA, ARO or OSD on GCP? NO. We are not looking to replace the existing stack. This still works great for Single cloud workload identity. We have seen SPIRE work in AWS/ROSA environments without issues but will validate for all clouds as part of productization. 
9. Telemetry - How is Telemetry handled on SPIRE Agent and Server? How is the telemetry data used for recovery/remediation? <TBD> Needs investigation. 

Concerns and Risks: 

Expected Results (what, how, when)

What incremental impact do you expect to create toward the company's Strategic Goals by delivering this outcome?  (possible examples:  unblocking sales, shifts in product metrics, etc. {}{} provide links to metrics that will be used post-completion for review & pivot decisions). {}For each expected result, list what you will measure and +when you will measure it (ex. provide links to existing information or metrics that will be used post-completion for review and specify when you will review the measurement such as 60 days after the work is complete)

SPIRE as the solution for machine<>machine authentication in OpenShift and layered products helps drive zero-trust in Multi-cluster and multi-cloud environments helping 

• Large scale FSI and Telco customers looking for strong attestation with zero-trust access controls
• Customer teams looking for machine<>machine access control for both K8s and non K8s workloads
• Single solution for identity across multiple cloud providers reducing investment needs for configuration and maintenance across clouds 

Post Completion Review – Actual Results

After completing the work (as determined by the "when" in Expected Results above), list the actual results observed / measured during Post Completion review(s).