> ## Documentation Index > Fetch the complete documentation index at: https://mintlify.com/aiven/aiven-docs/llms.txt > Use this file to discover all available pages before exploring further. # 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: **Human users** - Individual team members * Personal email addresses * Can log in to Aiven Console * Subject to authentication policies * Can belong to groups **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 **Centrally controlled** - With verified domain * Same as organization users * Restricted from creating organizations * Cannot edit their own profile * Managed by organization admins **Collections of users** - For bulk access management * Contain organization and application users * Simplify permission grants * Organization-wide scope ### Super Admin vs 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 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 **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 **Full project access** * All services in the project * Project configuration * Cannot modify billing group ```bash theme={null} # Grant admin role at project level avn project user-invite \ --project my-project \ --email user@company.com \ --role admin ``` **Manage services and infrastructure** * Create, edit, delete services * Configure VPCs and peering * Manage service integrations * Update IP allowlists * View logs ```bash theme={null} avn project user-invite \ --project my-project \ --email user@company.com \ --role operator ``` **Read-only plus data access** * View project and services * View connection information * Create databases and users * No infrastructure changes ```bash theme={null} avn project user-invite \ --project my-project \ --email user@company.com \ --role developer ``` **View-only access** * View services and configuration * View project event log * View tags and permissions * No changes allowed ```bash theme={null} avn project user-invite \ --project my-project \ --email user@company.com \ --role read_only ``` ### Granular permissions For more precise control, grant individual permissions: Create, edit, and delete application users View organization audit log View billing groups, invoices, and costs (read-only) Manage billing groups, payment methods, and addresses Add, edit, and remove domains Create and delete groups, manage group membership View organization VPCs Create and manage organization VPCs and peering Create and delete projects (cannot access project contents) Invite, deactivate, edit, and remove users View project logs View integration endpoints and service integrations 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 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 Click **Admin** → **Users** in the organization Click **Invite users** → Enter email addresses → Click **Send invitations** Assign roles/permissions at the organization, unit, or project level Invited user receives email and creates Aiven account (or logs in) ```bash theme={null} # Invite user via CLI avn organization user-invite \ --organization-id \ --email user@company.com # Grant organization admin role avn organization user-permission-grant \ --organization-id \ --user-email user@company.com \ --role role:organization:admin # Grant project admin role avn project user-invite \ --project my-project \ --email user@company.com \ --role admin ``` ### Removing users Removing a user from the organization revokes all their access to the organization's resources. ```bash theme={null} # Remove user from organization avn organization user-remove \ --organization-id \ --user-id # Remove user from specific project avn project user-remove \ --project my-project \ --email user@company.com ``` ### Deactivating managed users For organizations with verified domains, you can deactivate users: **Admin** → **Users** Find user → Click **Actions** → **Deactivate** Deactivated users lose all access immediately 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 **Admin** → **Application users** Click **Create application user** → Enter name and description Click **Generate token** → Set expiration and allowed IP ranges Copy token immediately (cannot be retrieved later) Assign permissions at organization, unit, or project level ```bash theme={null} # Create application user avn organization application-user-create \ --organization-id \ --name "Terraform Automation" \ --description "For managing infrastructure" # Generate token avn organization application-user-token-create \ --organization-id \ --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 \ --role admin ``` ### Application user best practices Separate application users for Terraform, CI/CD, monitoring, etc. Clearly indicate purpose: "GitHub Actions CI", "Datadog Integration" Limit tokens to trusted networks: ```bash theme={null} avn organization application-user-token-create \ --organization-id \ --user-id \ --cidr-blocks "203.0.113.0/24,198.51.100.0/24" ``` Revoke and regenerate tokens every 90 days: ```bash theme={null} # Revoke token avn organization application-user-token-revoke \ --organization-id \ --user-id \ --token-id ``` Grant only the minimum permissions needed 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 **Admin** → **Groups** Click **Create group** → Enter name and description Add organization users and application users to the group Assign roles/permissions to the group at organization, unit, or project level ```bash theme={null} # Create group avn organization group-create \ --organization-id \ --group-name "Backend Team" \ --description "Backend engineering team" # Add users to group avn organization group-member-add \ --organization-id \ --group-id \ --user-id # Grant group access to project avn project user-invite \ --project backend-prod \ --group-id \ --role admin ``` ### Example group structure ```yaml Engineering Team theme={null} Name: Engineering Team Members: - alice@company.com - bob@company.com - charlie@company.com Permissions: Organization: - organization:projects:write Unit (Engineering): - role:organization:admin (unit level) Projects: - backend-dev: admin - backend-prod: operator - frontend-dev: admin ``` ```yaml Finance Team theme={null} Name: Finance Team Members: - finance@company.com - accounting@company.com Permissions: Organization: - organization:billing:read - organization:billing:write ``` ```yaml CI/CD Automation theme={null} 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: alice@company.com 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 **Admin** → **Domains** → **Add domain** Add DNS TXT record to prove domain ownership 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 ```bash theme={null} # Add domain avn organization domain-add \ --organization-id \ --domain company.com # Get DNS verification record avn organization domain-get \ --organization-id \ --domain company.com # Verify domain after adding DNS record avn organization domain-verify \ --organization-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 ```bash theme={null} # 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](/platform/authentication) for accessing services. ## Best practices Assign permissions to groups instead of individual users for easier management Grant only the minimum access needed for each role Restrict production project access to a smaller group of users Never use personal accounts for CI/CD, Terraform, or monitoring integrations Enable managed users for centralized control and better security Review users, groups, and permissions quarterly. Remove unused access Maintain documentation of which groups have access to what resources Grant access at project level when possible, not organization-wide ## Next steps Configure SSO, SAML, and authentication policies Learn how to structure your resources Manage billing permissions for finance team Learn about Aiven's security features