Tenancy

The recommended way to onboard is via corectl tenancy.

The Core Platform is a multi-tenant platform where each tenant gets their own segregated environments and P2P.

What is a tenant?

A Tenancy is the unit of access to the Core Platform. It contains a readonly and an admin group and gives CI/CD actors (GitHub Actions) access to a namespace and a docker registry for images. Once you have a tenancy, you can add sub-namespaces for all your application testing needs.

Tenants are organized in a tree structure. For each tenant, we create a hierarchical namespace. A tenancy can be used to configure:

• resource quotas for a tenant and it’s children
• access control via network policies on a per-tenant basis. (e.g. granting another tenancy network access to your tenant)
• a shared prometheus instance for a tenant and its children

Manually raising a PR for a new tenancy

To add a tenancy raise a PR to the Environments Repo under tenants/tenants/ in your platform environments repo.

For example, if I want to create a tenancy with the name myfirsttenancy, then I will create a file named myfirsttenancy.yaml with the following structure:

name: myfirsttenancy 
parent: sandboxes
description: "Go Application"
contactEmail: go-application@awesomestartup.com
environments:
  - gcp-dev
repos:
  - https://github.com/<your-github-id>/go-application
adminGroup: platform-accelerator-admin@awesomestartup.com
readonlyGroup: platform-readonly@awesomestartup.com
cloudAccess:
  - name: ca # Cloud Access. Keeping it short so the username is also short, biggest one will be ca-connected-app-functional which is 27 chars, for mysql 8.0 needs to be 32max. For 5.7 16 max
    provider: gcp
    kubernetesServiceAccounts:
    - <namespace>/<k8s_service_account_name>
infrastructure:
  network:
      projects:
      - name: name
        id: <project_id>
        environment: <platform_environment>
betaFeatures:
  - k6-operator

• repos - All repos GitHub actions will get permission to deploy to the created namespaces for implementing your application’s Path to Production aka CI/CD
• cloudAccess - generates cloud-provider-specific machine identities for kubernetes service accounts to impersonate/assume. Note that the kubernetesServiceAccounts are constructed like <namespace>/<kubernetesServiceAccount> so make sure these match with what your application is doing. This Kubernetes Service Account is controlled and created by the App and configured to use the GCP service account created by this configuration.
• infrastructure - allows you to configure projects to be attached to the current one’s shared VPC, allowing you to use Private Service Access connections to databases in your own projects. This will attach your project to the one on the environment.
• betaFeatures - enables certain beta features for tenants:
  • k6-operator - allows running tests with K6 Operator.

Deleting a tenancy

To delete a tenancy, you have to:

1. Delete all the child tenancies.
2. Delete all the subnamespaces with applications of the tenancy.
3. Delete tenant configuration file related to the tenancy from the Environments Repo and merge the PR with this change.

Once the PR is merged and GitHub pipeline is finished running, the tenancy will be deleted.