Skip to main content

Infrastructure Credentials & Password Hardening

This operational reference provides the hardening guidelines and runbooks for eliminating default credentials and establishing zero-trust credential hygiene across the Okustera cloud platform.

It addresses both Deployment-Time Hardening (Day-0/1) and Post-Installation Lifecycle Rotation (Day-2).

Hardening Invariants​

In accordance with the Okustera Security Architecture and ISO/IEC 27001 ISMS standards:

  1. Zero Default Passwords: No infrastructure component (RabbitMQ, MariaDB, Keystone, Docker Registry, Memcached) may operate with vendor-default or upstream chart fallback passwords (password, admin, etc.).
  2. Template Sanitation: Placeholder tokens (e.g. OMC_*_SECURE_PASSWORD) must never be deployed to production workloads or committed to version control.
  3. Cryptographic Entropy: Passwords must be generated with at least 192 bits of entropy (openssl rand -hex 24 or Barbican KMS generation).
  4. Least-Privilege Network Exposure: Internal brokers, databases, and caches must never bind to public interfaces (0.0.0.0) or expose management consoles via unauthenticated ingress routes.

1. Installation Stage: Pre-Deployment Automated Hardening​

During automated installation, the platform orchestrator generates unique secrets prior to deploying Helm releases:

# Automated secret generation
SECRETS_FILE="infrastructure/undercloud/openstack-helm/values-poc/secrets.yaml"
umask 077

cat <<EOF > "${SECRETS_FILE}"
endpoints:
  identity:
    auth:
      admin:
        password: "$(openssl rand -hex 24)"
  oslo_db:
    auth:
      admin:
        password: "$(openssl rand -hex 24)"
  oslo_messaging:
    auth:
      admin:
        password: "$(openssl rand -hex 24)"
EOF
chmod 600 "${SECRETS_FILE}"

Helm deployment commands pass --values "${SECRETS_FILE}" to override upstream chart defaults across all service definitions.

2. Post-Installation: Day-2 Credential Rotation Runbooks​

When credentials need to be updated or rotated on a running cluster:

RabbitMQ Broker Rotation​

  1. Update Live Broker: 
    kubectl -n openstack exec rabbitmq-rabbitmq-0 -c rabbitmq -- \
      rabbitmqctl change_password rabbitmq "<NEW_PASSWORD>"
  2. Patch Kubernetes Secret: 
    kubectl -n openstack patch secret rabbitmq-admin-user --type='json' -p="[
      {\"op\": \"replace\", \"path\": \"/data/RABBITMQ_ADMIN_PASSWORD\", \"value\": \"$(echo -n '<NEW_PASSWORD>' | base64)\"}
    ]"
  3. Restart Dependent Services: 
    kubectl -n openstack rollout restart deployment/nova-api-osapi deployment/neutron-server deployment/cinder-api

MariaDB Galera Rotation​

  1. Update User Accounts in Database: 
    kubectl -n openstack exec mariadb-server-0 -c mariadb -- mysql -uroot -p<CURRENT_ROOT_PASS> -e "
      ALTER USER 'root'@'%' IDENTIFIED BY '<NEW_ROOT_PASS>';
      ALTER USER 'nova'@'%' IDENTIFIED BY '<NEW_NOVA_PASS>';
      FLUSH PRIVILEGES;
    "
  2. Update Secret & ConfigMaps: 
    kubectl -n openstack patch secret mariadb-dbadmin-password --type='json' -p="[
      {\"op\": \"replace\", \"path\": \"/data/MYSQL_DBADMIN_PASSWORD\", \"value\": \"$(echo -n '<NEW_ROOT_PASS>' | base64)\"}
    ]"
  3. Restart OpenStack Daemons: 
    kubectl -n openstack rollout restart deployment/keystone-api deployment/glance-api deployment/cinder-api

Keystone Identity & Service Users​

  1. Rotate Keystone Admin & Service Users: 
    openstack user set --password "<NEW_ADMIN_PASSWORD>" admin
    openstack user set --domain service --password "<NEW_SERVICE_PASSWORD>" nova
  2. Update Client OpenRC Files: Update admin-openrc.sh and ensure file permissions are restricted to 0600 (chmod 600 admin-openrc.sh).
  3. Purge Test Users: 
    openstack user delete keystone-test glance-test nova-test neutron-test cinder-test

3. Automated Hardening Audit​

Run the platform compliance check to verify that all default accounts are secured:

# Verify no service responds to unauthenticated or default credentials
curl -s -u "${TEST_USER}:${TEST_PASSWORD}" -H "Host: rabbitmq-mgr-7b1733" http://127.0.0.1/api/whoami
# Expected result: HTTP 401 / 403 or non-200 response

For complete technical specifications and script templates, consult the Credentials & Password Hardening Guide (docs/credentials_and_password_hardening_guide.md) in the core repository.