Skip to content

Commit

Permalink
Merge pull request #36 from ietf-wg-wimse/js-workload-identity
Browse files Browse the repository at this point in the history
Initial workload identity section
  • Loading branch information
jsalowey authored Jul 8, 2024
2 parents f9400c1 + 224581b commit dd404f9
Showing 1 changed file with 12 additions and 0 deletions.
12 changes: 12 additions & 0 deletions draft-ietf-wimse-arch.md
Original file line number Diff line number Diff line change
Expand Up @@ -79,8 +79,20 @@ Attestation is the function through which a task verifies the identity of a sepa

## Workload Identity

Workload identity often comprises multiple attributes that describe various aspects of a workload. These attributes can encompass diverse sets of information, including the workload's role within a system, the software it operates, and the hardware environment it utilizes. Different authorities across various parts of the system define these attribute sets. This architecture introduces a Workload Identifier for representing and referencing workloads, enabling diverse authorities with distinct identity attribute sets to consistently reference the workload.

The Workload Identifier consists of a concise string allocated within a namespace defined by a Trust Domain. This Workload Identifier is present in Workload Identity Tokens and X.509 certificates issued by the authority for the Trust Domain. The Workload Identifier is used to associate additional identity attributes to the workload through the use of tokens (workload attribute tokens?) or online look up services. It may also be used directly in authorization calculations and audit logs.

The Trust Domain consists of a string that matches the format of a fully qualified domain name. It is the intent that a Trust Domain is actually a domain name registered to the organization defining the Trust Domain, but this may not be true in all cases. The Trust Domain also maps to the issuer of cryptographically signed Workload Identity Tokens (WIT) or X.509 Certificate. The association between a Trust Domain and the cryptographic root of the signing authority for that Trust Domain must be made securely through an out-of-band mechanisms. [TODO: where should mechanisms be defined?]

The Trust Domain also defines how the rest of the Workload Identifier is constructed. The Workload Identifier may represent a type of workload such that the same identifier may be used by many instances of the same service. A Trust Domain may choose identifiers to represent a specific instance of a workload such that each workload of the same type will have a specific identity. The Trust Domain could choose a naming scheme that allows for both objects by imposing a hierarchical structure on the naming format.

The Trust Domain also defines which mechanisms are used to initially bootstrap a workload with a Workload Identifier and the mechanisms for a workload to obtain its workload identity credentials in the form of X.509 certificates and Workload Identity Tokens.

### Bootstrapping Workload Identity

[TODO: this section will need to be updated to discuss workload identifier as a concept as well]

A workload needs to obtain its identity early in its lifecycle. This identity is sometimes referred to as the "bottom turtle" on which further identity and security context is built.

Identity bootstrapping often utilizes identity information provisioned through mechanisms specific to hosting platforms and orchestration services. This initial bootstrapping information is used to obtain specific identity credentials for a workload. This process may use attestation to ensure the workload receives correct identity credentials. An example of a bootstrapping process follows.
Expand Down

0 comments on commit dd404f9

Please sign in to comment.