Skip to main content

Overview

The Resource Optimizer requires a dedicated service account with sufficient privileges to call the Compute API for live migration. Hardening this account — and restricting who can approve and execute action plans — prevents unauthorized workload movement and ensures a complete audit trail for all optimization activity.
Prerequisites
  • Administrator privileges on both the Resource Optimizer and Xloud Identity
  • Xloud Compute deployed and operational
  • Resource Optimizer services running (API, Decision Engine, Applier)

Service Account Hardening

The Applier uses a dedicated service account to authenticate against the Compute API. This account must have sufficient permissions to perform live migrations but should be scoped to the minimum necessary privileges.

Create a Dedicated Service Account

Create the user

Navigate to Admin → Identity → Users and click Create User.
FieldValue
Usernamewatcher-service
Emailwatcher@internal.xloud.tech
Projectservice
Roleadmin (required for live migration)
Set a strong password and save it to your secrets manager.

Restrict to service project

Ensure the watcher-service user has the admin role only in the service project — not in tenant projects. This limits blast radius if the account is compromised.

Protect watcher.conf Credentials

The watcher.conf file contains the Applier’s service account credentials. Restrict access to this file on controller nodes and verify the authentication configuration.

Automatic Credential Management

Service account credentials and authentication settings are automatically managed by XDeploy during deployment. XDeploy generates the [keystone_authtoken] section with the correct service account, endpoint URLs, and permissions.No manual configuration is required for standard deployments.

Custom Authentication Settings (Optional)

For advanced troubleshooting or custom authentication configuration, navigate to Advanced Configuration. In the Service Tree (left panel), select watcher. Click New File or select an existing watcher.conf from the File Browser (right panel).Modify the [keystone_authtoken] section in the Code Editor (center panel):
/etc/xavs/config/watcher/watcher.conf
[keystone_authtoken]
www_authenticate_uri = http://10.0.1.71:5000
auth_url = http://10.0.1.71:5000/v3
memcached_servers = 10.0.1.71:11211
auth_type = password
project_domain_name = Default
user_domain_name = Default
project_name = service
username = watcher-service
password = <service-account-password>

Save and Apply

Click Save Current File. Return to Operations and run reconfigure to apply the authentication changes.
Service credentials configured and applied via XDeploy.
Never store credentials in plain text outside /etc/xavs/. Do not commit watcher.conf to version control. If the password must be rotated, update watcher.conf and restart the Applier container.

RBAC Execution Policies

The Resource Optimizer enforces role-based access control on all API operations. The default policy grants:
OperationRequired Role
Create auditadmin
View audit resultsmember, reader
Approve action planadmin
Execute action planadmin
Cancel action planadmin
View action plansmember, reader

Verify Default Policies

List active RBAC policies
docker exec watcher_api \
  oslopolicy-list-redundant \
  --config-file /etc/watcher/watcher.conf

Restrict Execution to Named Administrators

To restrict action plan execution to a dedicated ops team without granting full admin, create a custom project-scoped role and override the policy:
Create an optimizer-operator role
openstack role create optimizer-operator
openstack role add optimizer-operator \
  --user ops-user \
  --project service
/etc/xavs/watcher/policy.yaml — execution override
"action_plan:execute": "role:optimizer-operator or role:admin"
Restart API after policy change
docker restart watcher_api

API Audit Logging

Enable verbose API request logging to record who approved and executed each action plan:
/etc/xavs/watcher/watcher.conf — audit logging
[DEFAULT]
use_journal = True

[oslo_middleware]
enable_proxy_headers_parsing = True
Logs are written to the container’s journal and to the XAVS log volume:
Follow real-time API logs
docker logs -f watcher_api
Search for execution events
docker logs watcher_api 2>&1 \
  | grep "action_plan.*execute"

TLS for API Communications

The Resource Optimizer API should be served behind the HAProxy endpoint which handles TLS termination. Verify that all client traffic reaches the API via HTTPS:
Verify API endpoint (should be HTTPS in production)
openstack endpoint list \
  --service optimization \
  -f table -c Interface -c URL
For internal controller communication, TLS on the RPC transport (RabbitMQ) is managed by the platform-wide [oslo_messaging_rabbit] configuration.

Rotation: Service Account Password

When rotating the Applier service account password:

Update the password in Xloud Identity

Set a new password
openstack user set watcher-service \
  --password "<new-strong-password>"

Update watcher.conf

Edit /etc/xavs/watcher/watcher.conf and update the password field under [keystone_authtoken].

Restart all Optimizer containers

Restart all Resource Optimizer services
docker restart watcher_api watcher_decision_engine watcher_applier

Verify authentication

Confirm API is reachable after rotation
watcher audit list
Audit list returns without authentication errors — password rotation complete.

Validation

Navigate to Admin → Resource Optimizer → Audits. Attempt to create an audit as a non-admin user — the action should be blocked with an authorization error.
Non-admin users cannot create audits or execute action plans.

Next Steps

Action Policies

Configure manual approval vs automatic execution policies for action plans.

Compute Integration

Verify the service account has compute permissions for live migration.

Architecture

Review which containers use the service account credentials.

Troubleshooting

Diagnose authentication failures and permission errors.