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