Home

lab-dev

A project to set up all the development tooling for a company/organization

It's opinionated, on how a company works, however, the opinions are simple (compared with others that could be implemented)

The project relies on Gitops and Kubernetes Operators (KubeOps). By using the Provided CRD's it will setup users, tenancies, services, and more.

Core Resources

Organisation

The organization is where we create the top-level structure

• Account - The engineers in the organization (will invite and remove engineers from the organization)
• Tenancy - This is a group of engineers (accounts), services, and libraries.
• Environment - The environments used for the development and running of services (develop, production, etc) - note one environment must represent production
• Zone - groups of hosting technologies that are associated with an environment and location.
• Platform-Services - These are special services that are reused across multiple environments and zones. This is not a resource unlike the others (but the icon represents several resources)

# /lab [REPO] <- manually created, but then this will assume ownership
#   dbones-labs.yaml
#
#   /platform-services
#     github.yaml
#     rancher.yaml
#     discord.yaml
#      
#   /users
#     dbones.yaml
#     bob.yaml
#     sammi.yaml
#
#   /tenencies
#     platform.yaml
#     galaxy.yaml
#     open-sourcerors.yaml
#
#   /environments
#     production.yaml
#     develop.yaml
#
#   /zones
#     apex.yaml
#     frontier.yaml

Platform Service

These are special services that reside outside of the environments we develop in. they are shared across, and now more commonly are cloud services.

• Github - CORE service - other than the usual source control, this has a critical control mecanism for controlling the access (IdP).
• Rancher - CORE service - this is how we implement GitOps (via fleet), and also control all compute clusters (adding the required RBAC controls)
• Discord - (replaceable - vNext scope) communications tool which will be configured to support the Tenancy Model.
• Vault - (vNext scope) a central secrets management component, as we set up services, teams, and databases, it will ensure all keys are rotated and safe.

Tenancy

This is a team of engineers, with the services and libraries that they develop.

Special conditions.

• A Tenancy can be marked as a Platform Tenancy - these tenancies are allowed to modify the Org and Zones
• Zone filter - this concept is to manage a tenancies access to certain zones (i.e. ones which are in the UK only or US)

• Member - which Accounts are members, note an Account can be a member of many Tenancies, member can have different types of membership
• FireFighter - this denotes if a member has been provided special access to fix something in an emergency situation. (this is not a Resource we create via gitops, but via kubeops and github issues)
• Library - software packages only require up to CI / Artifact store (not deployment)
• Service - deployable software requires CD, possible logins, and credentials

# /tenancy-galaxy [REPO] <- this is created from the above org repo
#   /members
#     dbones.yaml
#     sammi.yaml
#   /services
#     billing.yaml
#  /libraries
#    core.yaml
#   /cd
#     deployment yamls for the above components

Zone

A collection of clusters (Kubernetes, Postgres, etc), which are associated with an Environment, and location

can only be modified by a platform tenancy, with the correct filter.

• Kubernetes - a compute cluster, used to set up RBAC, deployments
• Postgres - database cluster, will setup databases, logins and roles
• RabbitMq - (vNext) - message broker, will setup logins

the 3 resource types represent a configured component (the configuration of the component can happen in this repo too, or externally)

# /zone-frontier this is production [REPO] <- this is created from the above org repo
#   /clusters
#     kubernetes-aqua.yaml
#     postgres-spike.yaml
#     postgres-goku.yaml
#     rabbitmq-asuna.yaml
#   /cd <- optional (vNext)
#     deployment yamls for the above components

Core Resource Interactions

Resources are no island when one is created, it will update the state of several components around it.

User

the user is key to most components, so an account is added to allow components, without any access to non-public resources.

Tenancy

Tenancies are an RBAC mechanism in most components

It works slightly differently with Components in a Zone vs Components that are Platform Services.

with Zoned components, it will only set up access if the Tenancy Filter is met

Member

Each component will use the roles which are set up via the Tenancy, this part will assign access

here is an oversimplified version of what to consider

note that the membership has different levels

• member - full member
• guest - someone that can contribute to a tenancy, but is not a member
• owner - is still just a member, just denotes someone that owns this tenancy

	Data	Compute	Code	Issues
Member	prod - no access / non-prod - CRUD	prod - read-only / non-prod - CRUD	Push / can view private repo's	Raise / Close / request FF / Approve FF
Guest	Prod - no access / non-prod - CRUD	prod - read-only / non-prod - CRUD	Pull / can view private repo's	Raise
Account not a member	no access	no access	Pull on all internal repo's	Raise

access to secrets is not allowed they should be linked up via the Services yaml.

Firefighter

a process to provide an account of the admin role in production for a limited amount of time

note this is the assignment of a role, not the creation of a burner account, any changes should be audited against the user, thus the role is assigned and then removed.

Credentials

Tech User

Each component that needs to be configured by this operator will require to provide credentials in the same namespace as the Organisation resource

there are 2 patterns we could employ (however there may be more)

• Primer setup - this is where a component is set up, either manual or by another automation process. and the credentials are copied into a Kubernetes secret
• Fleet setup - it is possible that within a Zone repository, to configure the component, and save credentials into a Kubernetes secret

• Github - Primer setup - API key
• Rancher - Primer setup - API key
• Postgres - Primer setup / Fleet setup - Postgres login

note that access to Zone components is a tricky thing to do.

the initial design is that the control plane (rancher local cluster) will have access to the components via certain secure means

• Kubernetes Clusters - this is using the out-of-the-box Rancher control mechanism, the cluster has HTTPS access to Rancher
• Postgres / Rabbit - these may require a jump-box/bastion to allow a encrypted SSH Tunnel to the component. where the bastion will implement further security measures such as IP Whitelisting & PEM file auth (this would be in addition to the credentials login at the component).

User ()

Even though the main aim of the game is to provide a closed/sealed architecture, we still need to provide engineers login access to components (in order to debug/operate)

in this case, there are 2 types of credential management that need to be considered

• Global - the account is on a public component, where the user will create their own credentials. the company may want to enforce a policy of MFA in these cases.
• Managed - This is where the lab.dev will create the account, and therefore create the credentials. In this case, the credentials need to be made available to the user and also fully managed.