# Omega Cloud -- Client Handover Pack (DRAFT 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, and the Acceptance Checklist.

## 1. Your identifiers

| Item | Value |
|---|---|
| Client short name (prefix on everything) | `{{TENANT_SHORT_NAME}}` |
| Your domain (the isolation boundary) | `{{TENANT_SHORT_NAME}}` |
| Your project | `{{TENANT_SHORT_NAME}}-prod` |
| Your private network / subnet | `{{TENANT_SHORT_NAME}}-net` / `{{TENANT_SHORT_NAME}}-subnet` ({{TENANT_CIDR}}) |
| Your router (gateway to the shared external network `provider-ext`) | `{{TENANT_SHORT_NAME}}-router` |
| Your SSH keypair (owned by the `-cluster` account) | `{{TENANT_SHORT_NAME}}-key` |
| Your automation credential (application credential on the `-svc` account) | `{{TENANT_SHORT_NAME}}-svc-cred` |

## 2. Your accounts and their exact rights

| Account | Signs in with | Rights (exactly these, nothing more) | Purpose |
|---|---|---|---|
| `{{TENANT_SHORT_NAME}}-domain-admin` | password | `manager` on your domain | your team's users, projects, and role grants |
| `{{TENANT_SHORT_NAME}}-cluster` | password | `member` + `load-balancer_member` on your project | Kubernetes cluster create/delete; owns the SSH keypair |
| `{{TENANT_SHORT_NAME}}-svc` | password, plus its application credential | `member` + `load-balancer_member` on your project | scripted/automated work (CI pipelines use the application credential) |

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

| Situation | Path |
|---|---|
| Quota change, password reset, custodian change | an authorized requester (named in your intake form) contacts {{ACCOUNT_CONTACT}} |
| Platform incident or outage affecting you | {{ACCOUNT_CONTACT}}, marked urgent |
| Suspected security issue (unexpected rights, unfamiliar activity in your domain) | {{ACCOUNT_CONTACT}}, marked urgent -- report first, investigate second |
| Shared substrate requests (new base image, new machine size, external connectivity) | {{ACCOUNT_CONTACT}} |
| Everything inside your domain | self-service -- see the Self-Service Guide |

## 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: ______________