> ## Documentation Index
> Fetch the complete documentation index at: https://infisical.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Machine identity attributes for ABAC

> Learn how to set metadata and leverage authentication attributes for 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

> [tab] Manually Configure Metadata
>
> **1. Navigate to the Access Control page on the organization sidebar and select a machine identity.**
>
> ![](https://mintlify.s3.us-west-1.amazonaws.com/infisical/documentation/platform/access-controls/abac/images/add-metadata-on-machine-identity-1.png)
>
> **2. On the machine identity page, click the pencil icon to edit the selected identity.**
>
> ![](https://mintlify.s3.us-west-1.amazonaws.com/infisical/documentation/platform/access-controls/abac/images/add-metadata-on-machine-identity-2.png)
>
> **3. Add metadata via key-value pairs and update the machine identity.**
>
> ![](https://mintlify.s3.us-west-1.amazonaws.com/infisical/documentation/platform/access-controls/abac/images/add-metadata-on-machine-identity-3.png)

#### Accessing attributes from machine identity login

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.

> [tab] OIDC Login Attributes
>
> 1. Navigate to the Identity Authentication settings and select the OIDC Auth Method.
> 2. In the **Advanced section**, locate the Claim Mapping configuration.
> 3. 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:
>
> ```json theme={"dark"}
> {
>   "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> }}
> ```
>
> ![](https://mintlify.s3.us-west-1.amazonaws.com/infisical/images/platform/access-controls/abac-policy-oidc-format.png)

> [tab] Kubernetes Login Attributes
>
> 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 }}
> ```
>
> ![](https://mintlify.s3.us-west-1.amazonaws.com/infisical/images/platform/access-controls/abac-policy-k8s-format.png)

> [tab] AWS Attributes
>
> 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
> ```
>
> ![](https://mintlify.s3.us-west-1.amazonaws.com/infisical/images/platform/access-controls/abac-policy-aws-format.png)

> [tab] Other Authentication Method Attributes
>
> At the moment we only support OIDC claims, Kubernetes attributes, and AWS attributes. Payloads on other authentication methods are not yet accessible.

#### 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 doesn't start with the given prefix, it is returned unchanged.

**Examples:**

Given `identity.auth.kubernetes.namespace` = `production-us-east`:

```handlebars theme={"dark"}
{{stripPrefix identity.auth.kubernetes.namespace 'production-'}} -> us-east
```

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

```handlebars theme={"dark"}
{{stripPrefix identity.auth.aws.arn 'arn:aws:iam::123456789012:'}}
-> user/example-user
```

**trimSuffix**

Removes a suffix from a string. The suffix can be a whole word or a glob pattern. When a
glob pattern could match more than one suffix, the shortest match is removed. If the end of
the string doesn't match the pattern, the string is returned unchanged.

A glob pattern can contain at most five `*` or `?` wildcards. A pattern with more
wildcards trims nothing.

**Examples:**

Given `identity.auth.kubernetes.namespace` = `myapp-pr-42`:

```handlebars theme={"dark"}
{{trimSuffix identity.auth.kubernetes.namespace '-pr-*'}} -> myapp
```

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

```handlebars theme={"dark"}
{{trimSuffix identity.auth.kubernetes.namespace '-pr-*'}} -> myapp
```

Given `identity.auth.kubernetes.namespace` = `myapp-pr-1`, where `-*` matches both `-pr-1`
and `-1`, the shorter suffix is removed:

```handlebars theme={"dark"}
{{trimSuffix identity.auth.kubernetes.namespace '-*'}} -> myapp-pr
```

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

```handlebars theme={"dark"}
/{{trimSuffix identity.auth.kubernetes.namespace '-pr-*'}}/**
```


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.