IAM Identities

An account has two kinds of identity, and neither is how a person joins it. A user is a name minted inside the account, for a program or a shared runner. A role groups permissions and is assumed for temporary credentials. A person joins by invitation, which Give a teammate access covers.

Managing Users

Creating Users

A user has no address and no sign-in, so it is the right identity for a build runner or another program and the wrong one for a person:

deployport iam users create <username>

Example:

deployport iam users create build-runner

Note

A new user starts with no policies attached, so it can do nothing until you attach one. Write a policy covers attaching it.

Adding a person instead

An invitation is emailed, it expires, and it carries the access the person gets when they accept. See Give a teammate access.

Managing Roles

A role is a collection of permissions that can be assumed by users or services to perform specific tasks. Unlike users, roles are not permanent identities - they provide temporary access to resources based on the policies attached to them. This makes roles ideal for applications, cross-service access, and situations where you need to delegate specific permissions without sharing long-term credentials.

Creating Roles

Create a new role for grouping permissions:

deployport iam roles create <rolename>

Example:

deployport iam roles create developer-access

Note

New roles start with no policies attached, meaning they have no permissions until policies are explicitly assigned. To assign permissions to your newly created role, learn how to create and attach identity policies.

Assuming Roles

Role assumption allows users to temporarily gain the permissions of a role, providing secure access to resources without permanent credential assignment.

To assume a role and get temporary credentials with that role’s permissions:

deployport iam roles assume <role-name>

Example:

deployport iam roles assume r1

This will output a temporary Access Key ID and Secret Access Key that inherit the permissions of the assumed role. You can use these credentials in a terminal, from an app, or in SDKs.

apiVersion: deployport.com/v1
kind: AssumedRoleContext
metadata:
  name: r1
spec:
  accessKeyID: "<example>"
  secretAccessKey: "<example>"
  region: us-east-1

I have role assumption credentials, how can I test or use them?

The quickest way is to use a separate profile in your local computer to test the credentials.

Say we want to name such profile temp-role, you could assume the role and configure it in another profile with a single command by piping deployport iam role assume and deployport configure assume:

deployport iam role assume r1 | deployport configure --profile=temp-role assume

The temp-role profile on your machine now has the credentials assumed for the role.

Linux & Mac

export DEPLOYPORT_PROFILE=temp-role

Windows

$env:DEPLOYPORT_PROFILE="temp-role"

Now you can run any other deployport command and it will use your role credentials.

Is there another way to test role credentials?

A more manual and advanced approach is to grab accessKeyID, secretAccessKey, and region and pass them directly to deployport configure as follows:

deployport configure -i <ACCESS_KEY_ID> -k <SECRET_ACCESS_KEY> -r <REGION>

Best Practices

• Invite people: a person joins by invitation, so what they may do is decided before they arrive
• Mint users for programs: a build runner or a shared tool gets a name inside the account
• Roles for temporary access: assume a role rather than handing out a long-lived key
• Meaningful Names: use descriptive names that say what the identity is for
• Regular Review: check what is still needed, and check what each policy is attached to

What’s Next?

Learn how to create and attach identity policies to grant permissions to your users and roles.