Difference between revisions of "Workload"
(→References) |
(→References) |
||
| Line 9: | Line 9: | ||
In summary, VMs, containers, services, and applications are often connected and dependent on each other while all needing distinct IAM strategies. | In summary, VMs, containers, services, and applications are often connected and dependent on each other while all needing distinct IAM strategies. | ||
| + | [[File:Workload.jpg]] | ||
==References== | ==References== | ||
[[Category: Computer]] | [[Category: Computer]] | ||
Latest revision as of 09:10, 7 July 2025
Definition
Workload
In the IAM taxonomy (see earlier post), all user constituencies and IAM domains present challenges and struggles, but the Workload IAM domain exceeds the others in that regard. 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: - 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. - 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.
