Identity Policies

Identity policies define what actions users and roles are allowed or denied on specific resources. They use a JSON-based policy language with statements that specify permissions, resources, and effects. A single identity policy can be attached to multiple users and roles, making them reusable within your account.

IAM provides some built-in policies for easy management. For example, the builtin.root identity policy looks as follows:

{
        "name":    "builtin.root",
        "builtin": true,
        "statements": [
                {
                        "actions":   ["*"], // allows all actions across all services
                        "resources": ["drn:v1 *"], // allows all resources in the account
                        "effect":    "allow",
                },
        ],
}

Want to inspect the definition of an identity policy?

You can use the show command to inspect an identity policy. For example, to inspect the builtin.root policy, run:

deployport iam identity-policies show builtin.root

This is, of course, a very permissive policy that shouldn’t be assigned lightly. You should always restrict your policies with minimum permissions. For that, you can define your own custom policies.

Creating a Custom Policy

Here’s an example policy that grants permission to create repositories:

{
        "name": "example", // Name of the policy
        "statements": [
                {
                        "actions": [
                                "binara:CreateRepository" // Action to allow creating repositories
                        ],
                        "resources": [
                                // You can use variables like ${username} to dynamically reference the user
                                // Note: Variables don't work with roles
                                "binara:Repository(${username}-production)",
                        ],
                        "effect": "allow" // Effect of the statement: "allow" or "deny"
                },
        ],
}

Generate a template policy file

deployport iam identity-policy > example.json

Modify the policy

Edit the example.json file according to your needs, defining the appropriate actions, resources, and effects.

Create the policy

deployport iam identity-policy create -f example.json

How can I change the name of the policy?

The policy name is defined in the JSON file. Look for the following field and modify it:

"name": "your-policy-name" // Change this to your desired policy name

Attaching Policies

Identity policies can be attached to both users and roles for flexible permission management. Each policy can be reused by attaching it to multiple users and roles as needed, allowing you to maintain consistent permissions across your organization without duplicating policy definitions.

Attaching to Users

Attach a policy to a user to grant or deny access:

deployport iam users policies attach -u <username> -p <policy-name>

Example:

deployport iam users policies attach -u john -p example

Attaching to Roles

You can also attach policies to roles:

deployport iam roles policies attach -r <role-name> -p <policy-name>

Example:

deployport iam roles policies attach -r developer-access -p repository-access

Listing Identity Policies

You can list all identity policies in the account with the following command:

deployport iam identity-policies list

Example:

- name: builtin.iam-manager
- name: builtin.root
- name: myrepo-consumer

You can also see how the identity policy is used by inspecting its attachments with --attachments:

deployport iam identity-policies list --attachments

Example:

- name: builtin.iam-manager
- name: builtin.root
- name: myrepo-consumer
  attachments:
    list:
      - targetDRN: iam:User(myrepo-consumer)

Policy Best Practices

Start Restrictive: Begin with minimal permissions and add more as needed
Use Variables: Leverage ${username} for user-specific resource access
Test Policies: Create test policies with limited scope before broad deployment
Document Purpose: The format of the policy JSON document and its attributes make it easy to express intention, however, it’s recommended to include JS-style comments (//) to clarify intention