S3crets Revealed: Automating Keys in Nutanix Objects
Intro
I make it a habit to write things down when the same question pops up a few times.
Recently, several folks asked how to automate user creation, key retrieval, and access rights for Nutanix Objects users and buckets.
Here’s the short version: it’s possible, it’s cleaner than it looks, and it saves a lot of clicking. Let’s walk through it step by step.
The Key Problem (pun intended)
When you create users in the Objects UI, it all looks simple. Open the Objects app in Prism Central, go to the Access Keys tab, and click Create User. Right there, you can make a new user and generate a key pair.
Now, if you check the Objects v4 API docs, you’ll notice something missing. There’s no direct way to handle IAM user management through that API. The UI can do it, but the API can’t.
User creation workflow in the UI
That’s because Nutanix “splits” user management between Prism Central IAM and Objects. It’s odd, since the UI lets you create a user and keys that don’t even show up in the IAM user list. But that’s the workflow we must reproduce if we want to automate it.
The Solution
Now that we know the gap, let’s look at what the APIs can do for us. The IAM v4 API lets us create users in Prism Central. After that, the createUserKey API can generate the access and secret keys we need. I used Postman to build and run these requests. It’s great for breaking APIs into small pieces and showing the matching code samples.
Let’s go through an example. I created a user called postmantest (creative, I know).The user type is LOCAL, since it’s not coming from a directory service. Because this is the first time we’re adding the user, we also need to set a password.
Curl representation of the createUser API call
If you explore the createUser API, you’ll notice a long list of optional fields. For this test, I only used the ones that are required for a successful call. No need to overcomplicate it.
Next, we call the createUserKey API to get an Access Key for our new user. To do that, check the API response from the previous call and note the value of the extId field. That’s the unique identifier for our user and what we’ll use in the next request.
CreateUser API return, highlighted the extID
The call syntax is https://{pc-ip}:9440/api/iam/v4.1.b1/authn/users/{userExtId}/keys - replace {userExtId} with the extID field value from the return of the createUser API.
CreateUserKey example
In this call, you’ll see a few optional fields like name and description for the key. More importantly, there’s the keyType field in the data section. Since we’re generating credentials for use with Nutanix Objects, set this field to OBJECT_KEY.
If everything went well, you’ll get a response that includes a new key pair, consisting of an accessKey and a secretKey. The secretKey is only shown once, and there’s a reason it’s called secret, so make sure to store it safely.
CreateUserKey response, highlighted the key pair
That’s it! We now have a user and a working access key pair ready to use with Nutanix Objects.
I got a user, now what?
The next question I usually get is, “How do I automate permissions for my buckets?”. Once you know how to create a user and retrieve the access keys, you’ll hit another small surprise. When you create a bucket, the user who creates it automatically gets full access. Everyone else gets nothing. That’s by design, but it matters if you plan to script the whole setup.
To apply permissions on S3 buckets, we use standard S3 APIs. That’s one of the nice things about Nutanix Objects being S3-compatible. But those APIs need valid access and secret keys. Here’s the catch: the Prism Central admin account doesn’t have those keys by default. Well, probably the admin has a key pair, but it is not accessible to us.
That means if you create a bucket as admin, you can’t automate permission assignments until you give another user an access key and secret key first. The simple fix is to create a service user that you use for automation. That user holds the keys, creates buckets, and applies permission changes. If you prefer stricter control, create a unique user for each bucket and assign access that way.
We’ll walk through another quick example. We’ll take the access and secret keys from our postmantest user and grant another user full access to a bucket called apidemo. First, we create a JSON policy file. I called it policy.json because naming things is hard.
JSON policy file with s3 permissions
The policy describes what actions a user can perform and which resources they apply to. In this case, it grants “Full Access” to our target IAM principal for the apidemo bucket. This is a standard representation of privileges on a bucket for S3 compatible storage. Pro Tip: AI is generally fantastic at writing these. For a simple full access it’s not needed, but for least-privilege models, this comes in very handy.
Next, we apply the policy. I used the AWS CLI for this example, but any S3-compatible tool works the same way. Run the command and point it to your policy file:
PutBucketPolicy example
Like many lab setups, mine doesn’t use proper certificates. So, I include --no-verify-ssl to skip certificate checks. You shouldn’t do that in production, but it helps for testing. Also note that “file://policy.json” will look for the file in the local working directory of the terminal.
And that’s it. Our IAM user now has full access to the apidemo bucket.
Successful user privilege assignment
Lessons learned (and mildly ranted about)
I shared some feedback internally on how this workflow could be smoother. A few fields in the UI don’t match the API names, which can confuse first-time users. It also feels strange that the UI can create users and keys while the API needs two separate steps. Still, once you understand the logic, the automation is simple.
Creating users, generating keys, and assigning permissions becomes fast and reliable. It takes a few calls, but it’s consistent once you script it.
Big thanks to my colleagues who asked the right questions and inspired this post!