Skip to main content

Domains

A Domain is a logical container for a collection of related Workloads within a Platform and is further subdivided by Environment. Workloads can be added to whatever Domain suits the business, reporting, or development needs of your organization. A Domain consists of one or more Environments, e.g. dev, stage, and prod, which are used to support different stages of a Workload's lifecycle.

Domain

Domains are loosely modeled after the notion of Domain-Driven Design (DDD). While Konfigurate does not take a particularly strong stance on DDD or how you structure Workloads, it does encourage the use of APIs to connect services versus sharing databases between them. This is a best practice that Konfigurate embraces because it reduces coupling which makes it easier to evolve services independently. A key aspect of this grouping will make certain tasks harder (though not necessarily impossible), on purpose, such as sharing a database between Domains. It also promotes more durable, product-aligned teams who own different parts of a system.

Domain-Driven Design

Domain-Driven Design (DDD) is a software development approach that focuses on modeling software closely around the business domain, using collaboration between developers and domain experts to ensure the software aligns with the business's needs.

Like Platforms, Domains play a critical role in Konfigurate's security and governance story. They allow us to assign permissions to different teams within a Platform. For example, if we have an Ecommerce Platform, we may have an Ecommerce group we grant basic permissions to at the Platform level, then specific Ecommerce teams may have ownership or elevated access within their respective Domains. We can also restrict which cloud services and APIs are available at the Domain level.

The Konfigurate hierarchy that Platforms and Domains provide facilitates a powerful way to enforce enterprise standards for a large organization while allowing for a high degree of flexibility and autonomy for a small organization. Basically, it allows for governance when you need it (and autonomy when you don't). This is particularly valuable for organizations with regulatory or compliance requirements, but it's equally valuable for companies wanting to enforce a "golden path"—that is, an opinionated and supported way of building something within your organization. It supports a DevOps model with significantly more standardization, structure, and efficiency.

Domains comprise several different resources which are created and managed by the Control Plane:

  • A Domain GCP folder which houses a project for each of the Domain's Environments
  • GCP projects for each Environment
  • A Domain CI/CD Service Account
  • A Domain GitLab group which houses the repositories for Domain Workloads
  • GitLab CI/CD variables set on the Domain group to support Workload Identity Federation
  • GitLab SAML group links which map identity provider groups specified on the Domain to GitLab roles
  • Environments, which in turn create Domain-Environment Service Accounts

The state of these items, along with the overall status of the Domain, can be viewed in the Konfigurate UI, as shown below.

Domain Details

Domains are managed declaratively using YAML definitions. These definitions live in the Control Plane repository and specify metadata and configuration for the Domain. This configuration includes a number of things:

  • Display name of the Domain
  • Environments (if not specified, uses the Platform's defaults)
  • Cloud services to enable (restricted by Platform's allowed list) or disable if relying on the Platform's defaults list (see here)
  • Group access management

Create a Domain

Domains are created via GitOps. When a Domain YAML definition is committed to the Control Plane's main branch, Konfigurate creates the Domain and all of its associated resources. This YAML can be created directly or using either the Konfigurate UI or Konfigurate CLI.

Below is an example demonstrating how to create a Domain which has dev, stage, and prod environments, enables several GCP services, and sets group permissions.

Refer to the Domain spec for the complete set of Domain configurations.

You can create a Domain by applying the YAML definition to the Control Plane repository.

apiVersion: konfig.realkinetic.com/v1alpha8
kind: Domain
metadata:
name: [DOMAIN ID]
namespace: konfig-control-plane
labels:
konfig.realkinetic.com/platform: [PLATFORM ID]
spec:
domainName: [DOMAIN DISPLAY NAME]
gcp:
envs:
- label: dev
- label: stage
- label: prod
services:
enabled:
- cloud-run
- cloud-sql
- pubsub
- redis
groups:
dev:
- dev@example.com
maintainer:
- maintainer@example.com
owner:
- owner@example.com

List Domains

The available Domains within a Platform can be viewed either with the Konfigurate UI or Konfigurate CLI.

  1. Navigate to the homepage of the Konfigurate UI.
  2. Navigate to the Platform you want to list Domains for by clicking the Platform in either the side navigation or in the main viewport.
  3. Domains will be displayed in both the side navigation and in the main viewport.

Platforms

Get Domain Details

Metadata for a Domain can be retrieved either with the Konfigurate UI or Konfigurate CLI.

  1. Navigate to the homepage of the Konfigurate UI.
  2. Navigate to the Platform containing the desired Domain by clicking the Platform in either the side navigation or in the main viewport.
  3. Locate the desired Domain in the main viewport and click the status icon.
  4. This will expand a sidebar containing information about the Domain such as links to the Domain in GitLab and GCP as well as its source definition, the Domain status, and the Domain's YAML applied to the Control Plane.

Platform Details

Domain Custom Resource Definition

NameTypeDescriptionRequired
apiVersionstringkonfig.realkinetic.com/v1alpha8true
kindstringDomaintrue
metadataobjectRefer to the Kubernetes API documentation for the fields of the metadata field.true
specobject
false
statusobject
false

Domain.spec

NameTypeDescriptionRequired
domainNamestring

Human readable name for the Domain. This must be unique within the Platform because the GCP Folder and Gitlab Group will have this name. Defaults to metadata.name.


true
gcpobject

Default: map[]

false
gitlabobject

Default: map[]

false
groupsobject
false

Domain.spec.gcp

NameTypeDescriptionRequired
createProjectsboolean

GCP Projects should be managed by Konfigurate.


Default: true

false
enableWorkloadIdentityboolean

Setup Workload Identity Federation mapping (and restriction to) the Domain's Gitlab CICD Service Account.



Default: true

false
envs[]object

The (authoritative) set of enviornments to create for this Domain. If not set, the Platform's defaultEnvs will be used.


false
manageFolderboolean

GCP Folder should be managed by Konfigurate.


Default: true

false
servicesobject
false
workloadIdentityobject

Default: map[]

false

Domain.spec.gcp.envs[index]

NameTypeDescriptionRequired
labelenum

Enum: dev, stage, prod

true
namestring
false
namespacestring
false
subnetNamestring

The name of the subnet to associate with this environment.


false

Domain.spec.gcp.services

NameTypeDescriptionRequired
disabled[]enum

List of services to disable for this Domain. This is used to remove services from the Platform's defaults (spec.gcp.services.defaults) list for this Domain.


false
enabled[]enum

The authoritative list of services to enable for this Domain. This is restricted by the Platform's spec.gcp.services.allowed list. Defaults to the Platform's spec.gcp.services.defaults if not set.



Default: [cloud-run cloud-sql pubsub redis firestore bigquery]

false

Domain.spec.gcp.workloadIdentity

NameTypeDescriptionRequired
enabledboolean

Setup Workload Identity Federation mapping (and restriction to) the Domain's Gitlab CICD Service Account.



Default: true

false

Domain.spec.gitlab

NameTypeDescriptionRequired
manageCIVarsboolean

Gitlab CI Vars should be managed by Konfigurate.


Default: true

false
manageGroupboolean

Gitlab Group should be managed by Konfigurate.


Default: true

false
serviceAccountNameVarstring

The Gitlab project CICD variable that will store the GCP IAM Service Account name (email).



Default: GCP_SA_EMAIL

false

Domain.spec.groups

NameTypeDescriptionRequired
dev[]string

If set, this group will be added to the dev GCP Project as 'Editor', and 'Viewer' to non-dev Projects. It will be added to the Gitlab Group as developer.


false
maintainer[]string

If set, this group will be added to the dev GCP Project as 'Editor', and 'Viewer' to non-dev Projects. It will be added to the Gitlab Group as maintainer.


false
owner[]string

If set, this group will be added to all GCP Projects as 'Editor'. It will be added to the Gitlab Group as maintainer.


false

Domain.status

NameTypeDescriptionRequired
gcpobject
false
gitlabobject
false
lastReconciledobject
false
readyboolean
false

Domain.status.gcp

NameTypeDescriptionRequired
domainFolderIdstring
false
domainServiceAccountstring
false
projectResources[]object
false

Domain.status.gcp.projectResources[index]

NameTypeDescriptionRequired
envstring
false
namestring
false
namespacestring
false
reasonstring
false
statusstring
false

Domain.status.gitlab

NameTypeDescriptionRequired
groupobject
false

Domain.status.gitlab.group

NameTypeDescriptionRequired
configsProjectIdstring
false
gcpSAVarNamestring
false
idstring
false
pathstring
false

Domain.status.lastReconciled

NameTypeDescriptionRequired
generationinteger
false
timestampstring
false