> ## Documentation Index > Fetch the complete documentation index at: https://docs.xloud.tech/llms.txt > Use this file to discover all available pages before exploring further. # API Security > Secure the Xloud API layer with token authentication, application credentials, rate limiting, CORS, RBAC policy enforcement, and mutual TLS between services. ## Overview All Xloud platform services expose REST APIs secured by Xloud Identity (Keystone). Authentication is token-based with configurable expiry, and the platform enforces authorization through a role-based access control (RBAC) policy engine. This page covers the full API security stack: authentication flows, application credentials, and rate limiting. It also covers audit logging, CORS configuration, and service-to-service mutual TLS. **Prerequisites** * An active Xloud account with the `member` or `admin` role * CLI tools installed: `openstack` CLI ([setup guide](/cli-setup)) * For application credentials: access to **Project → Identity → Application Credentials** *** ## Token-Based Authentication All API requests require a valid token issued by Xloud Identity. Tokens are scoped to a project and carry the user's role assignments for that project. ```mermaid theme={null} sequenceDiagram participant Client participant Keystone as Xloud Identity participant NovaAPI as Service API Client->>Keystone: POST /v3/auth/tokens (credentials) Keystone-->>Client: X-Subject-Token header Client->>NovaAPI: GET /v2.1/servers (X-Auth-Token: ) NovaAPI->>Keystone: GET /v3/auth/tokens (validate) Keystone-->>NovaAPI: Token valid + roles NovaAPI-->>Client: 200 OK + response ``` ### Token Scopes | Scope | Description | Use Case | | -------------- | ------------------------------ | ------------------------------- | | Project-scoped | Bound to a specific project | Standard user operations | | Domain-scoped | Bound to a domain | Domain administrator operations | | System-scoped | Platform-wide admin operations | Infrastructure management | | Unscoped | No project or domain binding | Token exchange only | ```bash title="Authenticate and get a token" theme={null} source admin-openrc.sh # Verify the active token openstack token issue ``` ```bash title="Expected output" theme={null} +------------+----------------------------------------------------------+ | Field | Value | +------------+----------------------------------------------------------+ | expires | 2025-03-18T11:00:00+0000 | | id | gAAAAABm... | | project_id | a1b2c3d4... | | user_id | e5f6g7h8... | +------------+----------------------------------------------------------+ ``` ```bash title="Authenticate via API directly" theme={null} curl -si -X POST https://:5000/v3/auth/tokens \ -H "Content-Type: application/json" \ -d '{ "auth": { "identity": { "methods": ["password"], "password": { "user": { "name": "admin", "domain": {"name": "Default"}, "password": "" } } }, "scope": { "project": {"name": "admin", "domain": {"name": "Default"}} } } }' | grep -i x-subject-token ``` The Xloud Dashboard handles token acquisition automatically at login. Session tokens are stored server-side and refreshed transparently. To inspect the active session token: 1. Navigate to **Project → API Access**. 2. Click **Download OpenStack RC File** to export credentials for CLI use. 3. Click **View Credentials** to see the active API endpoint list. Download the RC file and source it in your shell to configure CLI access with the same credentials used in the Dashboard session. *** ## Application Credentials Application credentials allow automation scripts and CI/CD pipelines to authenticate without embedding a username and password. They are scoped to a project, have configurable expiry, and can be restricted to specific API operations using access rules. Never store your account password in scripts or configuration files. Use application credentials instead. Application credentials can be revoked individually without changing the account password. Navigate to **Project → Identity → Application Credentials** and click **Create Application Credential**. | Field | Recommended Value | Notes | | --------------- | -------------------------- | ------------------------------------------------------ | | Name | `ci-deployment-prod` | Descriptive name identifying the use case | | Secret | Auto-generated | Store the secret securely — it is shown only once | | Expiration Date | Set an expiry | Required for compliance environments | | Roles | Select only required roles | Follow least-privilege | | Unrestricted | No | Leave unchecked to allow role inheritance restrictions | The secret is displayed only once after creation. Store it immediately in a secrets manager or CI/CD vault. It cannot be retrieved again. Click **Download openrc file**. Source this file in your automation environment to authenticate using the application credential. The downloaded RC file uses `OS_AUTH_TYPE=v3applicationcredential` — no password is stored in plaintext. ```bash title="Create application credential" theme={null} openstack application credential create \ --description "CI/CD deployment automation" \ --expiration "2026-01-01T00:00:00" \ ci-deployment-prod ``` ```bash title="Create with access rules (least privilege)" theme={null} openstack application credential create \ --description "Read-only monitoring credential" \ --access-rules '[ {"service": "compute", "method": "GET", "path": "/v2.1/servers"}, {"service": "identity", "method": "GET", "path": "/v3/projects"} ]' \ monitoring-readonly ``` ```bash title="Use application credential in scripts" theme={null} export OS_AUTH_TYPE=v3applicationcredential export OS_AUTH_URL=https://:5000/v3 export OS_APPLICATION_CREDENTIAL_ID= export OS_APPLICATION_CREDENTIAL_SECRET= openstack server list ``` *** ## RBAC Policy Enforcement Xloud enforces access control using oslo.policy rules. Every API operation checks the caller's token against the service's policy file before executing. ### Default Role Hierarchy | Role | Scope | Permissions | | --------------------- | ----------------- | ----------------------------------------------------- | | `admin` | System or project | Full access to all operations | | `member` | Project | Standard create/read/update/delete within the project | | `reader` | Project | Read-only access to project resources | | `heat_stack_owner` | Project | Manage orchestration stacks | | `load-balancer_admin` | Project | Manage load balancers | ### Custom Policy Overrides ```bash title="View current compute policy" theme={null} docker exec nova_api cat /etc/nova/policy.yaml 2>/dev/null || \ docker exec nova_api cat /etc/nova/policy.json ``` ```yaml title="Example: restrict live migration to system-admin only" theme={null} # /etc/xavs/nova-api/policy.yaml "os_compute_api:os-migrate-server:migrate_live": "role:admin and system_scope:all" ``` Xloud uses the standard RBAC model. Custom policy overrides should be placed in service-specific policy files and deployed via the XAVS config overlay mechanism. Do not modify policy files directly inside containers — changes are lost on restart. *** ## API Rate Limiting Rate limiting protects the platform from abuse and ensures fair resource allocation between projects. Limits are enforced at the HAProxy layer and within individual services. | Limit Type | Default | Configurable | | ------------------------- | --------------------- | ------------ | | Compute API (per user) | 50 POST / minute | Yes | | Compute API (per project) | 200 requests / minute | Yes | | Identity token issuance | 100 / minute | Yes | | Image upload | 10 / hour | Yes | ```yaml title="Configure compute rate limits" theme={null} # /etc/xavs/globals.d/_60_rate_limits.yml nova_api_rate_limits: | (POST, "*", .*, 50, MINUTE); (GET, "*", .*, 300, MINUTE) ``` *** ## CORS Configuration Cross-Origin Resource Sharing (CORS) controls which origins can make browser-based API requests. Configure allowed origins to match your Dashboard and any custom web applications. ```yaml title="Restrict CORS origins" theme={null} # /etc/xavs/globals.d/_60_cors.yml keystone_cors_allowed_origin: "https://connect." nova_cors_allowed_origin: "https://connect." neutron_cors_allowed_origin: "https://connect." ``` Do not set `allowed_origin: "*"` in production. This allows any website to make authenticated API calls on behalf of a user with an active session cookie, enabling cross-site request forgery (CSRF) attacks. *** ## Service-to-Service Authentication (Mutual TLS) Platform services authenticate to each other using service user accounts. When internal TLS is enabled, these connections also use mutual TLS certificate validation. ```mermaid theme={null} graph LR Nova -->|mTLS + service token| Neutron Nova -->|mTLS + service token| Cinder[Block Storage] Nova -->|mTLS + service token| Glance[Image Service] Neutron -->|mTLS + service token| Keystone[Identity] ``` Service accounts are created during deployment with minimal permissions scoped to inter-service operations only. Do not use these accounts for manual operations. ```bash title="List service users" theme={null} openstack user list --domain service ``` *** ## Audit Logging for API Calls All API calls are recorded in the audit log with the caller identity, token scope, target resource, and operation result. See the [Compliance and Auditing](/security/compliance) page for log format, retention, and aggregation configuration. ```bash title="View recent API audit events" theme={null} docker exec keystone grep "req-" /var/log/kolla/keystone/keystone.log | tail -20 ``` *** ## Next Steps Audit log format, retention, and compliance framework mapping Users, projects, domains, and federation configuration TLS configuration and certificate management Detailed application credential management guide