Workload

From MgmtWiki
Jump to: navigation, search

Definition

A computer Workload refers to the set of tasks, processes, or operations that consume computing resources—such as CPU, memory, storage, and network bandwidth—to achieve a specific outcome. It’s essentially the demand placed on a system by applications, services, or users at any given time.

Context

In the IAM taxonomy, all user constituencies and IAM domains present challenges and struggles, but the Workload IAM challenges may be the most difficult. The industry is lacking a good taxonomy of what constitutes a workload or a workload identity. Gartner categorizes workloads into four related (and interconnected!) user constituencies — services, applications, virtual machines (VMs), and containers. All four need IAM strategies.

The following examples explain the relationships and the concepts further and why each of the four types of workload need to be treated distinctly in an IAM taxonomy:

  1. A VM deployed in Microsoft Azure has an Azure-managed identity assigned to it. An Azure-managed identity includes the account, and Azure ensures that it has up-to-date credentials to help the VM identify itself to other services in Azure. The VM is running a self-managed or test/dev Kubernetes cluster. Each container is represented by using a Secure Production Identity Framework for Everyone (SPIFFE) environment that issues SPIFFE Verifiable Identity Documents (SVIDs) used for access control. The VM, Kubernetes, and the container are the infrastructure components that host a service, exposing a business API, requiring server credentials in the form of a certificate to terminate TLS. Like many applications, the service will also need client credentials in the form of API keys or database connection strings to connect to third-party systems.
  2. An AI agent is an application, acting on behalf of a human, to call a third-party service using an OAuth access token. Each AI agent requires its own workload identity (e.g., in the model context protocol [MCP], acquired using OAuth 2.0 Dynamic Client Registration) to authenticate the AI agent against the identity provider. The AI agent is also using a legacy (and always sub-par) API key to talk to a third-party service needing management.

In summary, VMs, containers, services, and applications are often connected and dependent on each other while all needing distinct IAM strategies. Workload.jpg

Identification

Persistence of the Identity of an Identified workload is not guaranteed by the current proposal where each container is represented by using a Secure Production Identity Framework for Everyone (SPIFFE) environment that issues SPIFFE Verifiable Identity Documents (SVIDs) used for access control.


Tom Jones (see below) The spec discusses node/workload attestation https://spiffe.io/docs/latest/spire-about/spire-concepts/#node-attestors this includes:

"verifying a private key stored on a Hardware Security Module or Trusted Platform Module attached to the node"

  • This hardware attestation would prove that the private Key has not been migrated. However, only the single mention exists, it's unlikely anybody uses it.

The other attestation options are all OS-level, and consequently there is no high-assurance way for a relying party to prove that private key is tied specific node/workload. Which is standard cloud practice.

  • SPIRE Architecture and Components

SPIRE is a production-ready implementation of the SPIFFE APIs that performs node and workload attestation in order to securely issue SVIDs to workloads, and verify the SVIDs of other workloads, based on a predefined set of conditions. This section...

References