7. Client Onboarding Flow

This section describes the end-to-end onboarding flow for a new Inari client.

Step 1: Cloud Account Preparation (Optional)

If the client does not have existing cloud accounts, create the account boundary manually or via Cloud Factory (target state, not v1):

• AWS: Organization OU + Account
• GCP: Folder + Projects
• Azure: Management Group + Subscription

Step 2: Control Plane Provisioning from Management Plane

Provision the client control plane using Crossplane running in the management plane. For the pilot, this creates an EKS cluster in the client's AWS account.

Management-plane Crossplane owns and reconciles:

1. AWS account / organization resources (manual or scripted for v1)
2. VPC, subnets, route tables, NAT gateways, security groups
3. EKS control plane and node groups
4. Cluster-level IAM roles, instance profiles, and OIDC provider
5. ArgoCD Helm installation
6. Initial ArgoCD Application pointing to clients/<client-id>/overlays/<env>/

Steps:

1. Configure a management-plane Crossplane ProviderConfig with a limited infrastructure-provisioning credential for the client's cloud account.
2. Apply the client control-plane claim (XRD/Composition) in the management plane.
3. Crossplane creates the infrastructure and installs ArgoCD.
4. Wait for the cluster API endpoint and admin kubeconfig to become available.
5. Verify the initial ArgoCD Application exists and is attempting to sync.

IAM integration:

• AWS: IRSA (IAM Roles for Service Accounts)
• GCP: Workload Identity
• Azure: AAD Pod Identity / Workload Identity

Step 3: Bootstrap Secret Injection

After the client cluster and ArgoCD are available:

1. 7KGroup operator or automation authenticates to the new cluster with admin credentials.
2. Install External Secrets Operator.
3. Create the initial bootstrap secret that allows ESO to authenticate to the client's secret store.
4. Verify ESO can read from the client's secret store.

Step 4: Baseline Deployment Verification

Client ArgoCD, installed and seeded by the management plane, syncs the overlay in waves, deploying the Inari baseline and client-specific configuration:

Wave	Components	Purpose
-5	Namespaces, External Secrets, pull secrets	Foundation
0	Dex, Alloy, Keycloak connection secrets	Auth + Observability
1	Backstage, Crossplane (workload)	Core platform
2	Hiroba Catalog XRDs	Platform abstractions
3	OPA policies, resource quotas	Guardrails
4	Backstage templates, Hiroba entities	Developer experience
5	Client workloads	End-user applications

Note: Cloud Factory XRD is not deployed in v1. It is target-state, post-v1.

Step 5: SSO Configuration

1. Configure Dex connectors for the client's IdP.
2. Test Backstage login.

Step 6: Observability Validation

1. Verify Vault PKI and cert-manager Vault issuer are working in the client cluster.
2. Verify Alloy has a valid mTLS certificate.
3. Verify Alloy remote_write to Mimir over mTLS.
4. Verify Alloy log push to Loki over mTLS.
5. Confirm the client appears in fleet Grafana.

Step 7: Read-Only Access

1. Create a read-only ServiceAccount and ClusterRoleBinding in the client cluster.
2. Generate a kubeconfig bound to that service account.
3. Deliver the kubeconfig to the client through a secure channel.
4. The client reads cluster state via kubectl as needed, but the primary read experience is Backstage.
5. No Kubernetes API OIDC is configured for client users.

---

See ADR-004, ADR-005, ADR-010, ADR-011, ADR-012, and ADR-013 in docs/architecture/decisions/.