Cloud User Directory

Cloud User Directory is how you sign in to Skippr Cloud, how you manage people on this account, and how you allow a function or CI identity to call Cloud services. Start with skippr-cloud login. After that, Cloud commands use your saved session.

Users of your product belong in an Auth user pool, not here.

Status: Preview. See API actions for the full command list.

You need an email address registered with Skippr Cloud.

bash

skippr-cloud login --email you@example.com

Skippr emails you a one-time code. Paste it at the prompt. Then confirm the session:

bash

skippr-cloud whoami

Later commands reuse that session. Sign out with skippr-cloud logout.

If a command fails with 401, sign in again. 403 means your account is not allowed to run that command.

Run Cloud commands such as skippr-cloud tables list-tables.
See who is on your account and assign roles.
Attach policies so a function or other workload can call Cloud services.
Create keys for Terraform, CI, or short-lived objects access.

For identities used by your application’s end-users, see Auth.

Manage the session

Task	Command
See who is signed in	`skippr-cloud whoami`
Sign out	`skippr-cloud logout`
Delete the account	`skippr-cloud auth delete-account`

Your team

These are the people who operate this Skippr Cloud account — CLI, Terraform, and the console.

bash

skippr-cloud auth list-directory-members
skippr-cloud auth list-directory-roles
skippr-cloud auth assign-directory-role --member-id '<memberId>' --role developer

Roles are owner, admin, developer, billing, and readonly.

You can list people already on the account and change their roles. Email invites and signing in with your company identity provider are coming soon. Until then, everyone on the team uses skippr-cloud login with email.

Policies

A function or CI identity cannot call Cloud services until you allow it. A function named hello uses workload principal fn/hello. An empty policy set denies Cloud actions for that principal.

bash

skippr-cloud auth create-policy --input - <<JSON
{
  "policyId": "hello-data",
  "policy": "permit (principal == Cloud::Principal::\"fn/hello\", action == Cloud::Action::\"tables:GetItem\", resource);",
  "attachedTo": ["workload:fn/hello"]
}
JSON

See Functions for the full package → register → authorize → invoke path.

Keys for Terraform and CI

Interactive work uses skippr-cloud login. Automation can use a key instead of a person at the prompt.

Use	What to create
Terraform, CDKTF, or scripts as yourself	An operator access key
CI or an application identity	A workload key, then attach a policy that allows the actions it needs
Short-lived objects access	`skippr-cloud auth get-credentials`

Create and revoke operator keys:

bash

skippr-cloud auth create-operator-access-key
skippr-cloud auth list-operator-access-keys
skippr-cloud auth revoke-operator-access-key --key-id <keyId>

The create response returns secretAccessKey once. Store it immediately.

Set CLOUD_ACCESS_KEY_ID and CLOUD_SECRET_ACCESS_KEY for those tools. See Terraform and CDKTF.

Application code should call the official SDK default chain (Client::from_env(), CloudClient.fromEnv(), CloudClient.from_env()) instead of embedding keys. On Skippr Cloud the SDK uses the workload role automatically. Terraform and CDKTF stay on paired access keys.

sk_live_… keys from the ELT runner do not sign in to Skippr Cloud, Terraform, or the CLI's Cloud commands. Use operator or workload SigV4 keys instead.

Wire details (JWT, SigV4 service names, and HTTP routes) are in the API reference and Auth OpenAPI.