Machine identities

Machine identities can have metadata set manually, just like users. In addition, during the machine authentication process (e.g., via OIDC), extra attributes called claims—are provided, which can be used in your ABAC policies.

Setting metadata on machine identities

Manually Configure Metadata

Navigate to the Access Control page on the organization sidebar and select a machine identity.

On the machine identity page, click the pencil icon to edit the selected identity.

Add metadata via key-value pairs and update the machine identity.

When machine identities authenticate, they may receive additional payloads/attributes from the service provider. For methods like OIDC, these come as claims in the token and can be made available in your policies.

OIDC Login Attributes
Kubernetes Login Attributes
AWS Attributes
Other Authentication Method Attributes

Navigate to the Identity Authentication settings and select the OIDC Auth Method.
In the Advanced section, locate the Claim Mapping configuration.
Map the OIDC claims to permission attributes by specifying:
- Attribute Name: The identifier to be used in your policies (e.g., department).
- Claim Path: The dot notation path to the claim in the OIDC token (e.g., user.department).

For example, if your OIDC provider returns:

{
  "sub": "machine456",
  "name": "Service A",
  "user": {
    "department": "engineering",
    "role": "service"
  }
}

You might map:

department: to user.department
role: to user.role

Once configured, these attributes become available in your policies using the following format:

{{ identity.auth.oidc.claims.<permission claim name> }}

For identities authenticated using Kubernetes, the service account’s namespace and name are available in their policy and can be accessed as follows:

{{ identity.auth.kubernetes.namespace }}
{{ identity.auth.kubernetes.name }}

For identities authenticated using AWS Auth, several attributes can be accessed. On top of the 3 base attributes, there’s 4 derived from the ARN. The example below includes comments showing how each derived attribute looks like based on this ARN: arn:aws:iam::123456789012:user/example-user

{{ identity.auth.aws.accountId }}
{{ identity.auth.aws.arn }}
{{ identity.auth.aws.userId }}

// Derived from ARN
{{ identity.auth.aws.partition }} // aws
{{ identity.auth.aws.service }} // iam
{{ identity.auth.aws.resourceType }} // user
{{ identity.auth.aws.resourceName }} // example-user

Template helper functions

In addition to referencing attributes directly, you can use helper functions to transform attribute values within your policy templates. stripPrefix Removes a prefix from the beginning of a string. If the string does not start with the given prefix, it is returned unchanged. Examples: Given identity.auth.kubernetes.namespace = production-us-east:

{{ stripPrefix identity.auth.kubernetes.namespace 'production-' }}  ->  us-east

Given identity.auth.aws.arn = arn:aws:iam::123456789012:user/example-user:

{{ stripPrefix identity.auth.aws.arn 'arn:aws:iam::123456789012:' }}  ->  user/example-user

trimSuffix Removes a suffix from the end of a string. The suffix is a glob pattern, using the same syntax as the Glob Match condition operator, so it can match a part of the value that varies. The shortest matching suffix is removed. If nothing at the end of the string matches the pattern, the string is returned unchanged. This is useful when a namespace or resource name carries a generated trailing segment. For example, an ArgoCD ApplicationSet using the pull request generator creates one namespace per open pull request, such as myapp-pr-1 and myapp-pr-42. Trimming the generated segment lets every one of those namespaces resolve to the same secret path as the base namespace, without writing a condition for each pull request. A pattern can contain at most five * or ? wildcards. A pattern with more than that trims nothing, and the string is returned unchanged. Examples: Given identity.auth.kubernetes.namespace = myapp-pr-42:

{{ trimSuffix identity.auth.kubernetes.namespace '-pr-*' }}  ->  myapp

Given identity.auth.kubernetes.namespace = myapp (nothing matches the pattern):

{{ trimSuffix identity.auth.kubernetes.namespace '-pr-*' }}  ->  myapp

You can combine this with a secret path condition so both the base namespace and its pull request namespaces read from one path:

/{{ trimSuffix identity.auth.kubernetes.namespace '-pr-*' }}/**

User identities