# 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

| 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.

This table is the authoritative statement of your accounts and their rights.
The other guides summarize it for their own workflow; if they ever seem to
disagree, this pack is correct.

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

--------------------------------------------------------------------------------

## Glossary

Plain-language definitions of the terms used across your document pack, grouped
by theme. Your own values (identifiers, accounts, endpoints) are in sections 1-3
above; this defines what the terms mean.

Your tenancy:

- Domain: your private, isolated boundary on the platform. Nothing inside it is
  visible to any other client, and vice versa. Your whole tenancy is one domain.
- Project: a container for resources (servers, networks, volumes, clusters)
  inside your domain, with its own quota. You are delivered one production
  project.
- Quota: the capacity envelope for a project -- how many instances, cores, how
  much memory, how many load balancers and floating IPs you may hold at once.
  Requests beyond quota are refused; changing it is a request to your account
  contact, not self-service.

Your accounts (exact rights in section 2):

- `{{TENANT_SHORT_NAME}}-domain-admin`: manages your team's users, projects, and
  role grants inside your domain. Identity work only, not workloads.
- `{{TENANT_SHORT_NAME}}-cluster`: the only account that creates and deletes
  Kubernetes clusters, using its password. It owns the cluster SSH keypair.
- `{{TENANT_SHORT_NAME}}-svc`: the automation account. All scripted and
  day-to-day work authenticates as this account's application credential.
- Application credential: a scoped, revocable secret tied to the `-svc` account.
  Automation uses it instead of a password; it can be revoked without touching
  the account. It cannot create Kubernetes clusters.

Networking:

- External network (`provider-ext`): the shared network that carries traffic to
  and from the outside world. You attach floating IPs from it.
- Floating IP: a routable address you allocate from the external network and
  attach to a server or load balancer to make it reachable. It counts against
  your quota even while unattached, so release ones you are not using.
- Network / subnet / router: your private network, the address range on it, and
  the device that connects it to the external network.
- Security group: a set of firewall rules controlling what traffic reaches your
  servers.
- Load balancer: distributes traffic across several backends behind one address.
  A Kubernetes LoadBalancer Service creates one automatically.

Compute and images:

- Instance (server): a virtual machine in your project.
- Flavor: a machine size (CPU, memory, disk). List them with
  `openstack flavor list`.
- Image: the operating-system or Kubernetes image a server or cluster boots
  from. The platform provides shared base images.
- Keypair: the SSH key used to reach servers. For clusters, the keypair is owned
  by the `{{TENANT_SHORT_NAME}}-cluster` account.

Kubernetes:

- Cluster template: the recipe (image, flavors, network driver, options) a
  cluster is built from. Templates must use the calico network driver, and must
  not set the Public or Hidden flag.
- Kubernetes cluster: a managed set of control and worker nodes in your project.
  You create it once and deploy into it many times.
- kubeconfig: the certificate-bearing file that grants access to a cluster's
  Kubernetes API. Treat it like a password.
- LoadBalancer Service: a Kubernetes Service that asks the platform for a real
  load balancer and floating IP, so an app inside the cluster is reachable from
  outside. Each one draws a load balancer and a floating IP from your quota.
- Ingress controller: a single LoadBalancer Service that routes to many internal
  Services by hostname or path -- one load balancer instead of many.

Access and trust:

- API endpoint / dashboard / region: your specific values are in section 3.
- CA bundle: the certificate file that lets your tools trust the platform's TLS
  certificates. Point your tools at it; never disable certificate verification.
- Catalog: the platform's own list of service endpoints. Discover endpoints from
  it (`openstack catalog list`) rather than hardcoding them.
- Secrets / certificates store: where you keep application secrets and TLS
  certificates for your project, referenced by your load balancers and apps.