Skip to main content

​
Overview

The Key Manager service is a critical security component — it stores the credentials that protect all other services. A compromise of the Key Manager backend could expose secrets used across your entire platform. This guide covers the key hardening areas.
Administrator Access Required — This operation requires the admin role. Contact your Xloud administrator if you do not have sufficient permissions.

​
Hardening Guidelines

Protect the master encryption key

The simple_crypto backend encrypts secrets using a master key. This key must be treated as the most sensitive credential in your platform:
  • Store master key files with 0400 permissions, owned by the Key Manager service user
  • Back up the master key to offline, encrypted media stored in a physically secure location
  • Never include the master key in container images, version control, or backup snapshots
  • Rotate the master key annually — plan a maintenance window for the re-encryption operation
Verify master key file permissions
ls -la /etc/xavs/key-manager/kek.conf
# Expected: -r-------- key-manager:key-manager
For PKCS#11 deployments:
  • Assign a dedicated HSM partition exclusively to Key Manager — never share partitions with other applications
  • Use separate HSM credentials for Key Manager vs. HSM administration tasks
  • Enable HSM audit logging and forward logs to your SIEM
  • Test HSM failover procedures quarterly — Key Manager unavailability during HSM outage blocks secret retrieval across all dependent services
  • Restrict physical HSM access to authorized datacenter staff only
All Key Manager API requests are logged. Forward logs to your centralized logging platform for:
  • Secret creation and deletion events
  • ACL modifications — track when access is granted or revoked
  • Secret retrieval (GET /v1/secrets/<id>/payload) — every access by every caller
  • Failed access attempts — potential indicators of unauthorized access attempts
Correlate Key Manager retrieval logs with the services that should legitimately access each secret. Unexplained retrieval events from unfamiliar callers warrant immediate investigation.
Enforce expiration on time-sensitive secrets:
  • Set expiration dates on all API tokens and temporary credentials
  • TLS certificates: track expiration in an external calendar — Key Manager does not send expiration alerts
  • Implement rotation workflows: create a new secret, update all references, then delete the old secret
  • Review and purge secrets without expiration dates quarterly — accumulation of orphaned secrets increases the blast radius of a breach
The Key Manager API should not be exposed on public networks:
  • Bind the API to the internal management network only
  • Configure firewall rules limiting port 9311 access to authorized service hosts
  • Use HAProxy frontend ACLs to restrict source IPs if Key Manager is behind a load balancer
  • Enable HTTPS on the Key Manager API endpoint — never transmit secrets over plain HTTP
  • Disable direct external access — all API calls should originate from within the platform

​
Security Checklist

ControlFrequencyNotes
Master key file permissionsAt deployment0400, owned by service user
Master key offline backupAt rotationEncrypted media, physically secured
Master key rotationAnnuallyPlan maintenance window
HSM partition isolationAt setupDedicated partition per service
Audit log forwardingContinuousSIEM integration
Orphaned secret reviewQuarterlyPurge secrets without expiration
Network access controlsAt deploymentFirewall rules on port 9311
HTTPS on API endpointAlwaysTLS termination at HAProxy

​
Next Steps

Backend Configuration

Configure HSM and KMIP backends for production deployments

Quotas

Set per-project limits to control resource consumption

Admin Troubleshooting

Diagnose security-related Key Manager service issues

DNS Security

Secure DNSSEC keys stored in Key Manager