Omega Cloud -- Client Handover Pack (TEMPLATE)

TEMPLATE NOTE (removed before delivery): fields written as {{THIS}} are filled in by us for each client at handover. Everything else is standard.

This document records exactly what you received when your environment was handed over on {{HANDOVER_DATE}}, how to reach the platform, how credentials must be handled, and the small set of platform rules you are asked to acknowledge. Keep it with your operational documentation; the companions are the Welcome letter, the Self-Service Guide, the CI/Automation Integration Guide, the Acceptance Checklist, and the scripts/ starter kit (plus, for teams using an AI assistant, the AI assistant guide and its skill package).

1. Your identifiers

2. Your accounts and their exact rights

These rights are deliberate and verified at handover. If any of your accounts ever appears to hold MORE than the rights above -- in particular anything called admin -- stop and report it to your account contact immediately; that is a platform incident, not a bonus.

3. Reaching the platform

• API endpoint (identity service): {{AUTH_URL}}
• Web dashboard: {{DASHBOARD_URL}}
• Region: {{REGION}}
• CA certificate: the platform's APIs use TLS certificates issued by our private certificate authority. You received the CA bundle file ({{CA_BUNDLE_FILE}}) with your credentials; point your tools at it (cacert in clouds.yaml, or the OS_CACERT environment variable). Do not disable certificate verification instead.

All other service endpoints (compute, networking, storage, load balancers, Kubernetes, secrets) are discovered from the platform itself -- never hardcode them. After authenticating, run:

openstack catalog list

and take endpoint URLs from there. If an endpoint ever changes, the catalog is updated and your tooling follows automatically.

4. Credential handling rules

1. Delivery: credentials were delivered out-of-band via {{CREDENTIAL_DELIVERY_METHOD}} to your two named custodians ({{CUSTODIAN_1}} and {{CUSTODIAN_2}}) -- never in email or ticket text. That rule also binds you: never paste a password or credential secret into email, chat, tickets, source code, or CI job logs.
2. Automation uses the application credential, never passwords. CI systems, scripts, and scheduled jobs authenticate with the {{TENANT_SHORT_NAME}}-svc-cred application credential. Account passwords never go into a pipeline, a repository, or a CI credential store. See the CI/Automation Integration Guide.
3. One person, one login. Your -domain-admin creates individual users for team members. Shared human logins are against the house rules.
4. Rotation and revocation are self-service. The -svc account can create additional application credentials (with expiry dates, if you wish) and delete compromised ones, without any ticket to us. Rotate by creating the new credential first, cutting your automation over, then deleting the old one.
5. Password resets are not self-service. If a password is lost, one of your named custodians requests a reset through your account contact. Keep both custodians current with us -- they are your recovery path.
6. Secrets are verified, not displayed. When you need to confirm a credential file is intact, check its length or format in a script; do not print it to a screen or log.

5. Support and escalation

6. Boundary items you are asked to acknowledge

These are the platform rules that protect your isolation and your neighbors'. Each one is enforced by the platform; acknowledging them saves you from discovering them the hard way.

1. No admin, ever. The platform refuses admin rights on client accounts by design. Your -domain-admin account already has every right you need inside your domain. Requests for admin will be declined; an admin grant that somehow appears is treated as an incident.
2. Kubernetes clusters are created and deleted only by the -cluster account, signed in with its password. The platform's cluster machinery cannot operate through an application credential -- a cluster create attempted with your automation credential fails every time. This is a platform constraint, not a configuration you can change.
3. The SSH keypair {{TENANT_SHORT_NAME}}-key belongs to the -cluster account. Do not delete it or recreate it under another account; clusters refuse to build with a key owned by anyone else.
4. Your -domain-admin account does identity work only. Do not run workloads or automation with it.
5. There is no self-service recovery for the -domain-admin password. If both custodians are unavailable, so is your recovery path. Keep two current custodians named with us at all times.
6. Quotas are set by us. Your accounts cannot raise them; an authorized requester asks instead. Treat quota-exceeded errors in automation as a signal to request a raise, not as a platform fault.
7. The shared substrate is ours: the external network provider-ext, the public floating IP pool, public base images, and machine sizes. You consume them; changes to them go through your account contact.
8. Your network range is {{TENANT_CIDR}}. You may create additional private networks freely, but choose ranges that do not overlap your on-premises or VPN networks if you ever plan to interconnect them.
9. Credential hygiene binds your side too (section 4): application credentials in automation, no passwords in CI, no secrets in logs or repositories, individual users for people.

Acknowledged for {{TENANT_SHORT_NAME}} by: __ (name, role)

Date: __