Skip to content

AODH Policies

Introduction

This document presents the permissions available for reader and member roles on the AODH service (alarm management) of Infomaniak Public Cloud, based on OpenStack default policies.

Context

Application Credentials must be created with the appropriate role according to functional needs. This matrix helps you choose the right role.

Legend

Symbol Meaning
✅ Allowed - The policy explicitly permits this action
❌ Forbidden - The policy explicitly denies this action

Alarm Management

Operation Endpoint Policy Reader Member Conditions
List alarms GET /v2/alarms telemetry:get_alarms ✅ ✅ Project only
Show alarm GET /v2/alarms/{id} telemetry:get_alarm ✅ ✅ Project only
Create alarm POST /v2/alarms telemetry:create_alarm ❌ ✅ Project member
Update alarm PUT /v2/alarms/{id} telemetry:change_alarm ❌ ✅ Project member
Delete alarm DELETE /v2/alarms/{id} telemetry:delete_alarm ❌ ✅ Project member

Alarm State Management

Operation Endpoint Policy Reader Member Conditions
Get alarm state GET /v2/alarms/{id}/state telemetry:get_alarm_state ✅ ✅ Project only
Set alarm state PUT /v2/alarms/{id}/state telemetry:change_alarm_state ❌ ✅ Project member

Alarm History Management

Operation Endpoint Policy Reader Member Conditions
Get alarm history GET /v2/alarms/{id}/history telemetry:alarm_history ✅ ✅ Project only

Query Operations

Operation Endpoint Policy Reader Member Conditions
Query alarms POST /v2/query/alarms telemetry:query_alarm ✅ ✅ Project only
Query alarm history POST /v2/query/alarms/history telemetry:query_alarm_history ✅ ✅ Project only

Capabilities Summary by Role

Granted permissions:

  • ✅ View all project alarms
  • ✅ View alarm states and configuration
  • ✅ View alarm history and events
  • ✅ Execute alarm queries
  • ✅ Monitor alarm status changes

Limitations:

  • ❌ No creation or modification actions
  • ❌ No alarm state changes
  • ❌ No alarm deletion

Granted permissions:

  • ✅ All Reader capabilities
  • ✅ Create new alarms
  • ✅ Modify existing alarms
  • ✅ Delete alarms
  • ✅ Change alarm states
  • ✅ Full alarm lifecycle management

Limitations:

  • ❌ Limited to project-scoped operations
  • ❌ Cannot access cross-project alarms

Usage Examples

Monitoring Dashboard Application

Use case: Read-only monitoring dashboard

Recommended role: reader

# Application Credential
role: reader

# Possible actions
- openstack alarm list
- openstack alarm show <alarm-id>
- openstack alarm state get <alarm-id>
- openstack alarm history show <alarm-id>

Alerting Management Application

Use case: Automated monitoring, CI/CD alerting

Recommended role: member

# Application Credential
role: member

# Possible actions
- openstack alarm create --name cpu-high --metric cpu_util --threshold 80
- openstack alarm update <alarm-id> --threshold 90
- openstack alarm state set <alarm-id> --state ok
- openstack alarm delete <alarm-id>

Context Variables

Policies use the following variables to determine authorizations:

Variable Description
%(project_id)s Current user's project ID

Important Notes

Best Practices

  1. Principle of least privilege: Use the reader role for monitoring applications that only need to view alarms
  2. Project isolation: All operations are scoped to the user's project
  3. State management: Only members can change alarm states and configurations
  4. Application Credentials management: Create specific credentials per monitoring use case

AODH Service Overview

AODH (Alarm as a Service) provides alarm functionality for OpenStack. It allows you to:

  • Create threshold-based alarms on metrics
  • Monitor resource states and trigger actions
  • Query alarm history and state changes
  • Integrate with notification systems

Scope Limitations

  • All alarm operations are limited to the current project scope
  • Cross-project alarm access requires system-scope permissions (admin role)
  • Quota management operations are excluded from user-level access