Skip to content

Roles and permissions

The platform uses two separate authorization layers:

  • Azure permissions for Marketplace deployment and customer-owned Azure resources;
  • Elastic permissions for Elasticsearch, Kibana, Fleet, and application data.

Permissions in one layer do not automatically grant access in the other.

Azure deployment permissions

The user deploying the Managed Application needs permission to create the application and its required resources in the selected Azure subscription.

Depending on the Marketplace plan and deployment configuration, the deployment can also require permission to create role assignments for managed identities and supporting Azure services.

Azure Contributor does not include all role-assignment permissions.

Use the least-privilege role approved by your Azure administrator.

Do not grant Owner simply as a troubleshooting workaround.

See Azure & Marketplace prerequisites for the deployment requirements.

Customer-owned Azure resources

Post-deployment tasks can require access to customer-owned resources outside the managed resource group.

Examples include:

Task Typical customer-owned scope
Create Private Endpoint Customer VNet or subnet
Configure private DNS Private DNS zone
Configure public DNS Customer DNS service
Update routing or firewall Customer network
Manage Marketplace subscription Azure subscription or billing scope

These permissions can belong to different teams.

A user does not need broad subscription-wide access merely because they need to update one DNS zone or subnet.

Managed resource group

The Managed Application controls the resources inside its managed resource group.

Azure can apply deny assignments or other restrictions that prevent customers from changing managed resources directly.

Do not attempt to bypass these controls.

Platform-level changes should use supported iVedha workflows:

  • AI chat: https://copilot.ivedha.cloud
  • Support portal: https://support.ivedha.com/

Elasticsearch and Kibana permissions

Elastic permissions should follow least privilege.

Common access categories include:

  • security administration;
  • cluster monitoring;
  • index or data-stream ingestion;
  • index read access;
  • search application access;
  • Kibana dashboard creation;
  • Kibana read-only access;
  • Fleet administration.

Avoid giving all users administrator privileges.

Administrator account

The built-in elastic account has unrestricted access to the Elasticsearch deployment.

Use it only when unrestricted administrative access is required.

For normal operations, prefer:

  • named users;
  • Microsoft Entra SSO;
  • Elastic roles;
  • scoped API keys.

The administrator password can be reset through the iVedha AI chat workflow.

Single sign-on

For organizations using Microsoft Entra ID, access can be mapped from Entra users or groups to Elastic roles.

The customer manages:

  • Entra users and groups;
  • application assignments;
  • organizational access approvals.

iVedha applies the supported Elasticsearch and Kibana SSO configuration.

See Configure single sign-on.

API keys

Applications and automated integrations should normally use scoped API keys instead of administrator credentials.

Create API keys with only the privileges required by the workload.

Examples include:

  • indexing into a specific data stream;
  • reading a specific search index;
  • accessing selected Elasticsearch APIs.

Do not embed administrator credentials in applications.

Fleet permissions

Fleet administration should be limited to users responsible for observability onboarding and Elastic Agent management.

Fleet administrators can manage:

  • agent policies;
  • integrations;
  • enrollment;
  • agent configuration;
  • supported upgrades.

Users who only view dashboards or search data normally do not need Fleet administration privileges.

OpenTelemetry workloads

Applications sending OpenTelemetry telemetry need only the credentials and permissions required by the configured ingestion path.

Application teams should not require Elasticsearch administrator access simply to send logs, metrics, or traces.

Where possible, use workload-specific credentials with the minimum required scope.

Support access

Support cases do not require sharing customer credentials.

Never send:

  • passwords;
  • API keys;
  • access tokens;
  • enrollment tokens;
  • private keys;
  • authentication headers.

Provide safe diagnostic evidence instead.

For detailed customer and iVedha ownership boundaries, see Shared responsibility.