Add support for cloud workload identity

Many cloud providers offer seamless integration with their identity story, which is often referred to as "Workload Identity". Although SpinKube should provide a cloud-agnostic implementation, I'll layout the user story and explain the concept using Azure services and Azure Workload Identity.

User Story

As an Spin App developer I want to use cloud services provided by Azure without having to specify access keys, passwords or tokens manually. Instead, I want to assign an Azure Identity to my Spin App and configure RBAC in Azure to allow that particular Azure Identity interacting with chosen Azure Services.

Azure Workload Identity

By deploying Azure Workload Identity to an Azure Kubernetes Service (AKS) cluster, and configuring the cluster itself accordingly, workloads could obtain tokens ( see concept) for interacting with Azure Services.

From an app developers point of view, two things must be done, to make a workload use Azure Workload Identity:

• the correct serviceAccountName must be specified on the Pod
• the label azure.workload.identity/use: "true" must be specified on the Pod

Spin Host vs Spin App

In the context of Spin, there are two layers in which users would want to use Azure Workload Identity in order to streamline and harden integrations and interactions with Azure Services:

• Spin Host level:
  • Using Azure Key Vault as Application Variable Provider
  • Using Azure CosmosDB or Azure Cache for Redis as key-value store
• Spin App level:
  • Accessing the data plane of various Azure Services e.g. Azure Storage Account, ...

No files, tests, or entry points are named. Start by reading the Azure Workload Identity concept links and separating the Spin Host and Spin App paths described in the issue. The scope and validation criteria need to be agreed before implementation can be considered done.