Managing IAM Users and IAM Roles for Object Storage
IAM User and IAM Role are identity models for FPT Object Storage that let you grant fine-grained, S3-compatible permissions using a JSON policy — similar to AWS IAM. Each IAM User has its own name, its own policy, and up to 2 access keys scoped strictly to what that policy allows.
IAM User and IAM Role are only available for buckets on the HCM-04 cluster. On other clusters, continue using SubUser to share limited bucket access — see Managing SubUsers.
IAM User vs. Access Key vs. SubUser
FPT Object Storage now has three separate places to generate S3 credentials. They are not interchangeable — check which one you're using before sharing a key:
| Access Key tab (legacy) | IAM User > Access Key | SubUser | |
|---|---|---|---|
| Cluster | All clusters | HCM-04 only | All clusters except HCM-04 |
| Permission scope | Full admin access to the account | Exactly what the IAM Policy allows | Read / Write / Read-Write / Full, per bucket |
| Key limit | 5 keys per region | 2 keys per IAM user | 2 keys per SubUser |
If you only need to share limited bucket access and your project is not on HCM-04, use SubUser instead — it is simpler to set up. Use IAM User when you need per-application, S3-policy-level control.
View the list of IAM users
Step 1: Go to the Object Storage Management menu, select the Project, then open the IAM User tab.
The IAM User tab only appears once Object Storage on HCM-04 is enabled for the Project. If you don't see this tab, your Project is not on HCM-04.
Step 2: The tab opens on the IAM Users view by default. Use the switcher at the top to toggle between IAM Users and IAM Roles.
Step 3: Use the search box to find an IAM user by name.
Create an IAM User
Step 1: On the IAM Users view, click Create IAM User.
Step 2: Enter the IAM User Name:
- 1–64 characters.
- Allowed characters: letters, digits, and
+ = , . @ _ -. - Must be unique within the account (name comparison is not case-sensitive).
Step 3: Click Create.
A newly created IAM user has no permission and no access key. You must attach an IAM policy and generate an access key before it can be used to call S3 — see the next two sections.
Assign a policy to an IAM user
An IAM user cannot access any S3 resource until you attach a policy. Each IAM user has exactly one JSON policy, which fully replaces any previous policy when saved.
Step 1: Open the IAM user's detail page, then select the IAM Policy tab.
Step 2: Click Create IAM Policy. The editor loads a sample template you can edit — for example, to grant read/write access to a single bucket:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowReadWriteOneBucket",
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:PutObject", "s3:ListBucket"],
"Resource": [
"arn:aws:s3:::YOUR-BUCKET-NAME",
"arn:aws:s3:::YOUR-BUCKET-NAME/*"
]
}
]
}
Step 3: Edit the Resource values to point to your own bucket(s), then click Save.
Step 4: Confirm the change. The dialog reminds you that saving replaces the entire policy and takes effect immediately for every access key already generated for this user.
- The
Resourcein a policy must belong to a bucket in your own account — buckets outside your account are always denied. - You cannot grant identity-management permissions (
iam:*), even through a wildcard*action. - You cannot grant
s3:PutBucketPolicy,s3:PutBucketAcl, ors3:PutObjectAclthrough this policy — these are always blocked as a safety guardrail, regardless of what you declare. - If an action you need doesn't seem to work, it may not be supported yet on the current cluster — contact FPT Cloud support to confirm before troubleshooting further.
To remove all permissions from an IAM user, open the IAM Policy tab and click Delete Policy — the user still exists, but every access key it holds immediately loses all S3 access.
Generate an access key for an IAM user
Step 1: Open the IAM user's detail page, then select the Access Key tab.
Step 2: Click Generate Key. Each IAM user can hold a maximum of 2 access keys at a time.
Step 3: The system generates an Access Key and Secret Key. Copy and store both values immediately — the Secret Key is shown only once and cannot be retrieved afterward.
Step 4: Click I've saved the secret key to close the panel.
If you close this panel before copying the Secret Key, the key is already created but its secret is lost permanently — you cannot recover it. The only way to fix this is to delete that key and generate a new one.
A newly generated key works immediately against the HCM-04 S3 endpoint — but if the IAM user has no policy yet, every request made with that key is still denied.
Delete (revoke) an access key
Step 1: In the IAM user's Access Key tab, find the key to remove, open the row menu, and select Delete.
Step 2: Type delete to confirm, then click Delete.
Deletion is immediate and permanent — there is no grace period and no way to undo it. If an application still needs S3 access, generate its replacement key first, update the application, and only then delete the old key.
Delete an IAM user
Step 1: From the IAM Users list, open the row menu and select Delete — or, from the user's detail page, use Delete IAM User in the Danger Zone section.
Step 2: Type delete to confirm, then click Delete. The system automatically revokes all of the user's access keys and removes its policy before deleting the user.
- The system does not scan your bucket policies for references to this IAM user before deleting it. If any bucket policy lists this user as a Principal, that statement silently stops matching — check and clean up your bucket policies yourself.
- IAM user names can be reused. If you later create a new IAM user with the same name, old bucket-policy statements referencing that name may start matching the new user again, unintentionally granting it old permissions. Clean up bucket policies before reusing a name.
- Deleting an IAM user does not affect buckets or data — buckets belong to the account, independent of any identity.
IAM Role
In this version, an IAM Role can be created and configured, but the portal does not yet provide a way to actually use it to obtain working credentials (no "assume role" action, no temporary-credential flow). Today, a role is useful only as a Principal reference — you can copy its ARN into a bucket policy — it does not by itself grant any IAM user working S3 access. This will be extended in a future release.
An IAM Role represents a shared set of permissions with a named list of IAM Users trusted to use it, so you don't need to copy the same policy onto every user individually.
Step 1: On the IAM User tab, switch to the IAM Roles view, then click Create Role.
Step 2: Enter the Role Name (same character rules as an IAM user name), and optionally tick the IAM Users allowed to use this role.
Step 3: Click Create.
Step 4: Open the role's detail page and select the Role Policy tab to attach a JSON policy — the same format and guardrails described above for IAM User policies apply, except the policy applies to every trusted IAM user of the role.
Step 5: To change which IAM Users are trusted to use the role, go to the Detail tab, open the IAM Users card, and click Edit IAM Users. Saving replaces the entire trusted-user list.
Step 6: To remove a role, open its detail page and use Delete IAM Role in the Danger Zone section, then type delete to confirm. This removes the role's policy and its trust relationships — it does not delete the IAM users that were trusted to use it.
As with IAM users, deleting a role does not scan bucket policies for references to it — clean up any bucket policy that lists the role's ARN as a Principal yourself.