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
Organization 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.
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 scenariosPermissions - 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 Admin - Full access to the organizationAllowed 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
Operator
Developer
Read Only
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 [email protected] \ --role admin
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 [email protected] \ --role operator
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 [email protected] \ --role developer
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 [email protected] \ --role read_only
Granular permissions For more precise control, grant individual permissions:
organization:app_users:write
Create, edit, and delete application users
organization:audit_logs:read
View organization audit log
organization:billing:read
View billing groups, invoices, and costs (read-only)
organization:billing:write
Manage billing groups, payment methods, and addresses
organization:domains:write
Add, edit, and remove domains
organization:groups:write
Create and delete groups, manage group membership
organization:networking:read
View organization VPCs
organization:networking:write
Create and manage organization VPCs and peering
organization:projects:write
Create and delete projects (cannot access project contents)
Invite, deactivate, edit, and remove users
project:integrations:read
View integration endpoints and service integrations
project:integrations:write
Create and manage integration endpoints and integrations
View project VPCs and peering connections
Create and manage project VPCs and peering
View service details (except logs and metrics)
Create, delete, and manage services
service:configuration:write
Change service configuration (cloud, region, network settings)
Perform queries, manage Kafka topics, PostgreSQL pools, etc.
View service logs (may contain sensitive information)
Read service secrets and view service users
Create and manage service users and credentials
Managing organization users Inviting users
Navigate to users
Click Admin → Users in the organization
Send invitation
Click Invite users → Enter email addresses → Click Send invitations
Grant access
Assign roles/permissions at the organization, unit, or project level
User accepts
Invited user receives email and creates Aiven account (or logs in)
# Invite user via CLI avn organization user-invite \ --organization-id < ORG_I D > \ --email [email protected] # Grant organization admin role avn organization user-permission-grant \ --organization-id < ORG_I D > \ --user-email [email protected] \ --role role:organization:admin # Grant project admin role avn project user-invite \ --project my-project \ --email [email protected] \ --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_I D > \ --user-id < USER_I D > # Remove user from specific project avn project user-remove \ --project my-project \ --email [email protected]
Deactivating managed users For organizations with verified domains, you can deactivate users:
Go to users page
Admin → Users
Deactivate
Find user → Click Actions → Deactivate
User cannot log in
Deactivated users lose all access immediately
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
Navigate to application users
Admin → Application users
Create user
Click Create application user → Enter name and description
Generate token
Click Generate token → Set expiration and allowed IP ranges
Save token
Copy token immediately (cannot be retrieved later)
Grant permissions
Assign permissions at organization, unit, or project level
# Create application user avn organization application-user-create \ --organization-id < ORG_I D > \ --name "Terraform Automation" \ --description "For managing infrastructure" # Generate token avn organization application-user-token-create \ --organization-id < ORG_I D > \ --user-id < APP_USER_I D > \ --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_I D > \ --role admin
Application user best practices
Create dedicated users per tool
Separate application users for Terraform, CI/CD, monitoring, etc.
Use descriptive names
Clearly indicate purpose: “GitHub Actions CI”, “Datadog Integration”
Restrict IP ranges
Limit tokens to trusted networks: avn organization application-user-token-create \ --organization-id < ORG_I D > \ --user-id < APP_USER_I D > \ --cidr-blocks "203.0.113.0/24,198.51.100.0/24"
Rotate tokens regularly
Revoke and regenerate tokens every 90 days: # Revoke token avn organization application-user-token-revoke \ --organization-id < ORG_I D > \ --user-id < APP_USER_I D > \ --token-id < TOKEN_I D >
Use least privilege
Grant only the minimum permissions needed
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
Navigate to groups
Admin → Groups
Create group
Click Create group → Enter name and description
Add members
Add organization users and application users to the group
Grant permissions
Assign roles/permissions to the group at organization, unit, or project level
# Create group avn organization group-create \ --organization-id < ORG_I D > \ --group-name "Backend Team" \ --description "Backend engineering team" # Add users to group avn organization group-member-add \ --organization-id < ORG_I D > \ --group-id < GROUP_I D > \ --user-id < USER_I D > # Grant group access to project avn project user-invite \ --project backend-prod \ --group-id < GROUP_I D > \ --role admin
Example group structure Engineering Team
Finance Team
CI/CD Automation
Name : Engineering Team Members : - [email protected] - [email protected] - [email protected] Permissions : Organization : - organization:projects:write Unit (Engineering) : - role:organization:admin (unit level) Projects : - backend-dev : admin - backend-prod : operator - frontend-dev : admin
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: [email protected] 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
Add domain
Admin → Domains → Add domain
Verify ownership
Add DNS TXT record to prove domain ownership
Users become managed
All users with email addresses on verified domain automatically become managed users
Managed user restrictions
Cannot create organizations - Only organization admins canCannot edit profile - Name, email managed by organization adminsCentralized control - Organization admins can deactivate, delete, reset passwordsVisible even outside org - Organization can see all users with their domain
# Add domain avn organization domain-add \ --organization-id < ORG_I D > \ --domain company.com # Get DNS verification record avn organization domain-get \ --organization-id < ORG_I D > \ --domain company.com # Verify domain after adding DNS record avn organization domain-verify \ --organization-id < ORG_I D > \ --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 servicesManaged 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
Best practices
Use groups, not individual grants
Assign permissions to groups instead of individual users for easier management
Principle of least privilege
Grant only the minimum access needed for each role
Separate production access
Restrict production project access to a smaller group of users
Use application users for automation
Never use personal accounts for CI/CD, Terraform, or monitoring integrations
Verify your domain
Enable managed users for centralized control and better security
Audit regularly
Review users, groups, and permissions quarterly. Remove unused access
Document permission structure
Maintain documentation of which groups have access to what resources
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
