cloudnx.in

Identity & access management

CloudNx IAM mirrors AWS IAM closely enough that anyone familiar with AWS will feel at home. The vocabulary is intentional: root users, IAM users, groups, policies, and access keys.

Identity types

TypeLogin methodCapabilities
Root userEmail + password (the address you signed up with)Owns the account. Full access to billing, IAM, every resource. There is exactly one per account.
IAM userAccount ID + username + password (console)
OR access key + secret (programmatic)		Sub-identity under a root account. Permissions controlled by attached policies.
Team memberTheir own root credentials, joined to your org via inviteRole-based: admin / member / viewer. Sees your org’s resources via team membership rather than IAM policies.

When to use which: use team members for full-time employees who own their own credentials, IAM users for service accounts and contractors with scoped access, and the root user for nothing day-to-day.

Account ID

Every account has a 9-digit numeric account_id (e.g. 100000003). It’s the ownership boundary for all resources — IAM users, instances, buckets, and billing records all key on it.

Find your account ID at the top of /iam, or the cloudnx whoami command output. Share the vanity URL https://cloudnx.in/signin/<account_id> with IAM users — it pre-fills the IAM tab and the account-ID field on the sign-in screen.

Policies

A policy is a JSON document that lists allowed and denied actions. CloudNx ships five managed policies you can attach as-is:

NameEffect
CloudNxFullAccess Everything. Equivalent to root, except it can’t change billing or delete IAM itself.
CloudNxReadOnlyAccess List + describe everything; no mutations.
CloudNxComputeFullAccess Full control over instances, ASGs, snapshots, volumes.
CloudNxStorageFullAccess Full control over buckets and objects.
CloudNxBillingReadOnly View invoices, transactions, and current balance.

You can also create custom policies with the same JSON format AWS uses — {Effect, Action, Resource} — at /iam → Policies.

Action format

Every API call is gated by an action of the form service:Verb. Examples:

  • compute:CreateInstance
  • compute:ListInstances
  • storage:CreateBucket
  • iam:CreateUser
  • billing:Read

Evaluation

  1. Collect every policy attached to the user, plus every policy attached to every group the user belongs to.
  2. If any statement explicitly Denys the action → reject.
  3. If at least one statement Allows the action → permit.
  4. Otherwise → reject (deny by default).

Groups

A group is a collection of IAM users that share policies. Use them when more than one user should have the same permissions — e.g. a developers group with CloudNxComputeFullAccess attached.

Access keys

Access keys are the credential pair (access_key_id, secret_key) that programmatic clients use. The CLI signs requests with these via SigV4 — the secret never travels over the wire after creation. The secret is shown once at creation time and hashed thereafter; lose it and you must rotate.

Each key tracks last_used_at so you can prune dormant credentials.

MFA

Both root users and IAM users can enable TOTP-based MFA via /settings → 2FA. After enabling, sign-in requires the 6-digit code from your authenticator app in addition to the password.

Password policy

Root account owners can set a password policy at /settings — minimum length, required character classes, expiry days. The policy applies on every IAM password create and reset.

Recommended setup

  1. Enable MFA on the root user immediately after signup.
  2. Create one IAM user per developer + service. Never share credentials.
  3. Group developers under a developers group with CloudNxComputeFullAccess.
  4. For CI / production deploys, create a dedicated IAM user with only CloudNxComputeFullAccess (or a custom narrower policy) and a dedicated access key — never the root key.
  5. Rotate access keys quarterly. Use the last_used_at column to prune unused keys.
PreviousFAQ
Next Billing, autopay & GST