Users and Permissions

Learn how to manage users, groups, roles, and permissions in your Aiven organization.

Aiven’s role-based access control (RBAC) system lets you manage who can access your organization’s resources and what actions they can perform. Users can be granted roles and permissions at the organization, organizational unit, or project level.

User types

Aiven supports several types of users with different characteristics:

Organization Users

Human users - Individual team members

• Personal email addresses
• Can log in to Aiven Console
• Subject to authentication policies
• Can belong to groups

Application Users

Non-human users - For automation and integrations

• Programmatic access only
• Cannot log in to Console
• Not subject to authentication policies
• Use tokens for API/CLI/Terraform

Managed Users

Centrally controlled - With verified domain

• Same as organization users
• Restricted from creating organizations
• Cannot edit their own profile
• Managed by organization admins

Groups

Collections of users - For bulk access management

• Contain organization and application users
• Simplify permission grants
• Organization-wide scope

Super Admin vs Organization Admin

Super Admin

Unrestricted access to everything:

• All organization resources and settings
• Can rename and delete the organization
• Can manage other super admins
• Can manage authentication policy
• Full billing access
• Cannot be removed by other admins

Limit super admin access to only essential personnel for security.

Organization Admin

Full access except:

• Cannot delete organization
• Cannot rename organization
• Cannot manage super admins

Can do everything else:

• Manage all units, projects, services
• Full billing access
• Manage users, groups, domains, IdPs
• Configure authentication policy
• Create and delete organizational units

Roles and permissions

Aiven uses two concepts for access control:

• Roles - Predefined sets of permissions for common scenarios
• Permissions - Granular actions on specific resources

Roles and permissions are cumulative. A user’s effective access is the combination of all roles and permissions granted directly to them and through groups they belong to.

Organization roles

role:organization:admin · Role

Admin - Full access to the organization

Allowed actions:

• View and change billing information
• Change authentication policy
• Create and delete organizational units and projects
• Move projects between units
• Invite, deactivate, and remove users
• Create, edit, and delete groups
• Manage application users
• Add and remove domains
• Manage identity providers

Cannot:

• Delete organization
• Manage super admins

Project roles

Admin

Full project access

• All services in the project
• Project configuration
• Cannot modify billing group

# Grant admin role at project level
avn project user-invite \
  --project my-project \
  --email [e-mail] \
  --role admin

Operator

Manage services and infrastructure

• Create, edit, delete services
• Configure VPCs and peering
• Manage service integrations
• Update IP allowlists
• View logs

avn project user-invite \
  --project my-project \
  --email [e-mail] \
  --role operator

Developer

Read-only plus data access

• View project and services
• View connection information
• Create databases and users
• No infrastructure changes

avn project user-invite \
  --project my-project \
  --email [e-mail] \
  --role developer

Read Only

View-only access

• View services and configuration
• View project event log
• View tags and permissions
• No changes allowed

avn project user-invite \
  --project my-project \
  --email [e-mail] \
  --role read_only

Granular permissions

For more precise control, grant individual permissions:

Organization permissions

organization:app_users:write · Permission

Create, edit, and delete application users

organization:audit_logs:read · Permission

View organization audit log

organization:billing:read · Permission

View billing groups, invoices, and costs (read-only)

organization:billing:write · Permission

Manage billing groups, payment methods, and addresses

organization:domains:write · Permission

Add, edit, and remove domains

organization:groups:write · Permission

Create and delete groups, manage group membership

organization:networking:read · Permission

View organization VPCs

organization:networking:write · Permission

Create and manage organization VPCs and peering

organization:projects:write · Permission

Create and delete projects (cannot access project contents)

organization:users:write · Permission

Invite, deactivate, edit, and remove users

Project permissions

project:audit_logs:read · Permission

View project logs

project:integrations:read · Permission

View integration endpoints and service integrations

project:integrations:write · Permission

Create and manage integration endpoints and integrations

project:networking:read · Permission

View project VPCs and peering connections

project:networking:write · Permission

Create and manage project VPCs and peering

project:services:read · Permission

View service details (except logs and metrics)

project:services:write · Permission

Create, delete, and manage services

service:configuration:write · Permission

Change service configuration (cloud, region, network settings)

service:data:write · Permission

Perform queries, manage Kafka topics, PostgreSQL pools, etc.

service:logs:read · Permission

View service logs (may contain sensitive information)

service:secrets:read · Permission

Read service secrets and view service users

service:users:write · Permission

Create and manage service users and credentials

Managing organization users

Inviting users

1. Navigate to users

   Click Admin → Users in the organization

2. Send invitation

   Click Invite users → Enter email addresses → Click Send invitations

3. Grant access

   Assign roles/permissions at the organization, unit, or project level

4. User accepts

   Invited user receives email and creates Aiven account (or logs in)

# Invite user via CLI
avn organization user-invite \
  --organization-id <ORG_ID> \
  --email [e-mail]

# Grant organization admin role
avn organization user-permission-grant \
  --organization-id <ORG_ID> \
  --user-email [e-mail] \
  --role role:organization:admin

# Grant project admin role  
avn project user-invite \
  --project my-project \
  --email [e-mail] \
  --role admin

Removing users

Removing a user from the organization revokes all their access to the organization’s resources.

# Remove user from organization
avn organization user-remove \
  --organization-id <ORG_ID> \
  --user-id <USER_ID>

# Remove user from specific project
avn project user-remove \
  --project my-project \
  --email [e-mail]

Deactivating managed users

For organizations with verified domains, you can deactivate users:

1. Go to users page

   Admin → Users

2. Deactivate

   Find user → Click Actions → Deactivate

3. User cannot log in

   Deactivated users lose all access immediately

4. Reactivate if needed

   Use same process to reactivate the user

Managing application users

Application users provide secure programmatic access for automation, CI/CD, and integrations.

Creating application users

1. Navigate to application users

   Admin → Application users

2. Create user

   Click Create application user → Enter name and description

3. Generate token

   Click Generate token → Set expiration and allowed IP ranges

4. Save token

   Copy token immediately (cannot be retrieved later)

5. Grant permissions

   Assign permissions at organization, unit, or project level

# Create application user
avn organization application-user-create \
  --organization-id <ORG_ID> \
  --name "Terraform Automation" \
  --description "For managing infrastructure"

# Generate token
avn organization application-user-token-create \
  --organization-id <ORG_ID> \
  --user-id <APP_USER_ID> \
  --description "Production Terraform" \
  --max-age-seconds 7776000  # 90 days

# Grant project admin permission
avn project user-permission-grant \
  --project my-project \
  --application-user-id <APP_USER_ID> \
  --role admin

Application user best practices

1. Create dedicated users per tool

   Separate application users for Terraform, CI/CD, monitoring, etc.

2. Use descriptive names

   Clearly indicate purpose: “GitHub Actions CI”, “Datadog Integration”

3. Restrict IP ranges

   Limit tokens to trusted networks:

   avn organization application-user-token-create \
     --organization-id <ORG_ID> \
     --user-id <APP_USER_ID> \
     --cidr-blocks "203.0.113.0/24,198.51.100.0/24"
   
4. Rotate tokens regularly

   Revoke and regenerate tokens every 90 days:

   # Revoke token
   avn organization application-user-token-revoke \
     --organization-id <ORG_ID> \
     --user-id <APP_USER_ID> \
     --token-id <TOKEN_ID>
   
5. Use least privilege

   Grant only the minimum permissions needed

6. Audit regularly

   Review application users and delete unused ones

Application users can have organization admin access. Secure their tokens carefully to prevent abuse.

Managing groups

Groups simplify permission management by allowing you to grant access to multiple users at once.

Creating groups

1. Navigate to groups

   Admin → Groups

2. Create group

   Click Create group → Enter name and description

3. Add members

   Add organization users and application users to the group

4. Grant permissions

   Assign roles/permissions to the group at organization, unit, or project level

# Create group
avn organization group-create \
  --organization-id <ORG_ID> \
  --group-name "Backend Team" \
  --description "Backend engineering team"

# Add users to group
avn organization group-member-add \
  --organization-id <ORG_ID> \
  --group-id <GROUP_ID> \
  --user-id <USER_ID>

# Grant group access to project
avn project user-invite \
  --project backend-prod \
  --group-id <GROUP_ID> \
  --role admin

Example group structure

Engineering Team

Name: Engineering Team
Members:
  - [e-mail]
  - [e-mail]
  - [e-mail]
  
Permissions:
  Organization:
    - organization:projects:write
  Unit (Engineering):
    - role:organization:admin (unit level)
  Projects:
    - backend-dev: admin
    - backend-prod: operator
    - frontend-dev: admin

Name: Finance Team  
Members:
  - [e-mail]
  - [e-mail]
  
Permissions:
  Organization:
    - organization:billing:read
    - organization:billing:write

Name: CI/CD Automation
Members:
  - github-actions (application user)
  - gitlab-ci (application user)
  
Permissions:
  Projects:
    - backend-dev: operator
    - frontend-dev: operator

Permission inheritance

Permissions granted at higher levels automatically apply to lower levels:

Organization (organization:projects:write)
└── Unit: Production
    └── Project: backend-prod (admin role)
        └── Service: postgres-1
        └── Service: redis-1

User with both permissions can:

• Create projects anywhere in organization (organization:projects:write)
• Fully manage backend-prod project and all its services (admin role)

Permissions are cumulative, not restrictive. A less permissive role at project level does NOT override more permissive permissions from organization level.

Example: Cumulative permissions

User: [e-mail]

Permissions granted:
1. Organization level: project:services:write
2. Project level: read_only role

Effective access on project:
- Can read all project details (from read_only)
- Can create and delete services (from project:services:write)

The higher-level permission grants write access even though the project-level role is read-only.

Managed users and domains

Verify your organization’s domain to enable managed users:

Enabling managed users

1. Add domain

   Admin → Domains → Add domain

2. Verify ownership

   Add DNS TXT record to prove domain ownership

3. Users become managed

   All users with email addresses on verified domain automatically become managed users

Managed user restrictions

• Cannot create organizations - Only organization admins can
• Cannot edit profile - Name, email managed by organization admins
• Centralized control - Organization admins can deactivate, delete, reset passwords
• Visible even outside org - Organization can see all users with their domain

# Add domain
avn organization domain-add \
  --organization-id <ORG_ID> \
  --domain company.com

# Get DNS verification record
avn organization domain-get \
  --organization-id <ORG_ID> \
  --domain company.com

# Verify domain after adding DNS record
avn organization domain-verify \
  --organization-id <ORG_ID> \
  --domain company.com

Managed users combined with authentication policies provide the strongest security for your organization.

Service users

Service users are different from organization/application users - they’re database/service-specific accounts:

• Per-service - Created within individual services (PostgreSQL, Kafka, etc.)
• Service access only - For connecting applications to services
• Managed in service - Not at organization or project level

# Create service user (PostgreSQL example)
avn service user-create \
  --project my-project \
  --service postgres-1 \
  --username app_user

# Get user credentials
avn service user-get \
  --project my-project \
  --service postgres-1 \
  --username app_user

Learn more about authentication methods for accessing services.

Best practices

1. Use groups, not individual grants

   Assign permissions to groups instead of individual users for easier management

2. Principle of least privilege

   Grant only the minimum access needed for each role

3. Separate production access

   Restrict production project access to a smaller group of users

4. Use application users for automation

   Never use personal accounts for CI/CD, Terraform, or monitoring integrations

5. Verify your domain

   Enable managed users for centralized control and better security

6. Audit regularly

   Review users, groups, and permissions quarterly. Remove unused access

7. Document permission structure

   Maintain documentation of which groups have access to what resources

8. Use project-level permissions

   Grant access at project level when possible, not organization-wide

Next steps

Authentication

Configure SSO, SAML, and authentication policies

Organizations & Projects

Learn how to structure your resources

Billing & Payment

Manage billing permissions for finance team

Security

Learn about Aiven’s security features