Security Token Service (STS) and IAM Roles

The VAST Cluster includes a Security Token Service (STS) server, which allows users or other principals to assume IAM roles and then obtain temporary access keys for S3 buckets on the VAST Cluster.

The Security Token Service (STS), used with IAM roles, is used to control user access to S3 buckets in the cluster in a secure and scalable way. STS acts as a trusted intermediary that issues temporary security credentials after verifying a user or service’s identity. These credentials are linked to IAM roles, which define a set of permissions that can be assumed by users dynamically.

STS supports OIDC Providers such as Okta, Entra ID, and Keycloak, which can be configured in the VAST Cluster.

Users can access S3 buckets on the cluster using the temporary access keys that the STS server returns when they successfully assume an IAM role. If the user creates objects in the bucket, they are owned by the role (or the bucket owner, depending on configuration), not by the user that assumed the role.

Creating IAM Roles using the VAST Web UI

Navigate to the User Management page in the VAST Web UI, and select the IAM Roles tab.
Click Create New Role.
In the General section, enter these fields
Name
A unique name for the role.
Description
A description of the role (optional).
In the Attach Identity Policies section, select identity policies, from the list, that will be associated with the role. These policies are applied to users who assume the role, to determine their permissions and the resources they can access. Details for the selected policies are shown in JSON format in the Identity Policies pane, on the right. See Managing Identity Policies for details about creating identity policies.
In the Trust Policy section, configure a trust policy for the role. Trust policies define which users can assume the role, and which users are denied. Follow the steps in the Creating Trust Policies for IAM Roles section.

Creating Trust Policies for IAM Roles

Trust policies define who is allowed to assume an IAM role, and under which conditions. They are specific to the role itself.

In the Statement ID field, enter a name for the statement.
Select the Effect of the actions in the statement: Allow or Deny. When applied, the policy will either allow or deny the selected actions.
Enter a list of one or more principals, who will be affected by the policy. A principal is the OIDC provider. Use the format
```
"Principal": {"Federated": "oidc-provider/<issuer>"}
```
For example:
```
 ""Principal": {"Federated": "oidc-provider/login.microsoftonline.com/<tenant>/v2.0";}"
```
Note
oidc-provider/ is hard-coded, and issuer is obtained from the "iss" attribute of the JWT.
Optionally, In the Conditions section add conditions for the statement. Conditions qualify when a policy statement applies to resources. Follow these steps to add conditions to the policy:
1. Click Add Condition.
2. Select a Condition Key, from the list. This is the element that is tested by the condition.
3. Select a Qualifier, from the list. This indicates whether the condition applies to any or for all values in a request.
  Note
  This field applies only to some condition keys.
4. Select an Operator.
5. Enter a list of Values, separated by commas.
  For example, this condition checks the 'aud' field in a JWT for specific users.
```
"Condition": {
    "StringEquals": {"login.microsoftonline.com/<tenant>/v2.0:aud": "0oalggs6d5D6exca65d7"}
}
```
6. Repeat above steps for additional conditions for the same statement.

The Default policy allows all principals to assume the role:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "sts:*"
        }
    ]
}

Managing IAM Roles using the VAST Web UI

Modifying IAM Roles

You can modify an IAM role. Changes in roles only affect principals who assume the role after the changes, not users who have already assumed the role.

In the IAM Roles tab, right-click on the role to be edited, and select Edit.
Make any changes to the role as necessary. You cannot change the name of the role.
Click Update.

Revoking Access Keys for IAM Roles

Temporary S3 access keys are generated for the role by the STS server. You can revoke the keys for all users who have assumed the IAM role, effectively denying them access to the resource.

In the IAM Roles tab, right-click on the role, and select Revoke All Access Keys.

Deleting IAM Roles

IAM roles can be deleted if they are not the owners of any S3 views. If they are owners of views, they must be removed as owners first before the role can be deleted.

Access keys associated with the role become invalid when the role is deleted.

In the IAM Roles tab, right-click on the role, and select Delete.

Name	A unique name for the role.
Description	A description of the role (optional).