Organization management

• 1: Registry Overrides
• 2: Creating an organization

1 - Registry Overrides

Overview

Greenhouse supports overriding registry sources for both Helm charts and container images. This allows pulling resources from alternative registries instead of their original sources.

Registry overrides operate at two levels:

• Helm chart repositories: Configured per Catalog
• Container image registries: Configured per Organization

Helm Chart Registry Overrides

Helm chart repositories can be overridden by configuring the repository field in the overrides array of a Catalog resource.

Configuration

apiVersion: greenhouse.sap/v1alpha1
kind: Catalog
metadata:
  name: my-catalog
  namespace: my-organization
spec:
  sources:
    - repository: https://github.com/cloudoperators/greenhouse-extensions
      resources:
        - kube-monitoring/plugindefinition.yaml
        - perses/plugindefinition.yaml
      ref:
        branch: main
      overrides:
        - name: kube-monitoring
          repository: oci://my-registry.example.com/charts/kube-monitoring
        - name: perses
          alias: perses-mirror
          repository: oci://my-registry.example.com/charts/perses

Fields:

• name: Name of the PluginDefinition to override (required)
• repository: The alternative Helm chart repository URL (optional)
• alias: The alternative name of the PluginDefinition (optional)

Example

apiVersion: greenhouse.sap/v1alpha1
kind: Catalog
metadata:
  name: production-catalog
  namespace: production-org
spec:
  sources:
    - repository: https://github.com/cloudoperators/greenhouse-extensions
      resources:
        - "*/plugindefinition.yaml"
      ref:
        branch: main
      overrides:
        - name: kube-monitoring
          repository: oci://internal-registry.company.com/greenhouse/kube-monitoring
        - name: alerts
          repository: oci://internal-registry.company.com/greenhouse/alerts
        - name: dashboards
          repository: oci://internal-registry.company.com/greenhouse/dashboards

Container Image Registry Overrides

Container image registries are overridden using a ConfigMap referenced by the Organization resource. This applies to all plugins deployed within the organization.

Configuration

Create a ConfigMap with a containerRegistryConfig key:

apiVersion: v1
kind: ConfigMap
metadata:
  name: registry-mirrors
  namespace: my-organization
data:
  containerRegistryConfig: |
    registryMirrors:
      ghcr.io:
        baseDomain: "mirror.company.com"
        subPath: "ghcr-mirror"
      docker.io:
        baseDomain: "mirror.company.com"
        subPath: "dockerhub-mirror"
      quay.io:
        baseDomain: "mirror.company.com"
        subPath: "quay-mirror"
      registry.k8s.io:
        baseDomain: "mirror.company.com"
        subPath: "k8s-mirror"    

Reference the ConfigMap in the Organization:

apiVersion: greenhouse.sap/v1alpha1
kind: Organization
metadata:
  name: my-organization
spec:
  description: My Organization with Registry Mirrors
  configMapRef: registry-mirrors

Fields:

• baseDomain: The hostname of the mirror registry (required)
• subPath: The path within the mirror where images are stored (required)

Image Transformation

When deploying plugins, image references are automatically rewritten to use the configured mirror registries.

Example: GitHub Container Registry

Original image:

ghcr.io/cloudoperators/greenhouse:v1.0.0

Mirror configuration:

registryMirrors:
  ghcr.io:
    baseDomain: "mirror.company.com"
    subPath: "ghcr-mirror"

Transformed image:

mirror.company.com/ghcr-mirror/cloudoperators/greenhouse:v1.0.0

Example: Docker Hub official images

Original image:

nginx:latest

Mirror configuration:

registryMirrors:
  docker.io:
    baseDomain: "mirror.company.com"
    subPath: "dockerhub-mirror"

Transformed image:

mirror.company.com/dockerhub-mirror/library/nginx:latest

Note: Docker Hub official images are automatically prefixed with library/.

Example: Docker Hub user repositories

Original image:

bitnami/postgresql:15

Mirror configuration:

registryMirrors:
  docker.io:
    baseDomain: "mirror.company.com"
    subPath: "dockerhub-mirror"

Transformed image:

mirror.company.com/dockerhub-mirror/bitnami/postgresql:15

Complete Example

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: my-organization-config
  namespace: my-org
data:
  containerRegistryConfig: |
    registryMirrors:
      ghcr.io:
        baseDomain: "registry.internal.company.com"
        subPath: "external/ghcr"
      docker.io:
        baseDomain: "registry.internal.company.com"
        subPath: "external/dockerhub"
      quay.io:
        baseDomain: "registry.internal.company.com"
        subPath: "external/quay"
      registry.k8s.io:
        baseDomain: "registry.internal.company.com"
        subPath: "external/kubernetes"
      my-public-registry.com:
        baseDomain: "registry.internal.company.com"
        subPath: "external/custom"    

---
apiVersion: greenhouse.sap/v1alpha1
kind: Organization
metadata:
  name: my-org
spec:
  description: My Organization with Internal Registry Mirrors
  configMapRef: my-organization-config

2 - Creating an organization

Before you begin

This guides describes how to create an organization in Greenhouse.

Creating an organization

An organization within the Greenhouse cloud operations platform is a separate unit with its own configuration, teams, and resources tailored to their requirements. These organizations can represent different teams, departments, or projects within an enterprise, and they operate independently within the Greenhouse platform. They allow for the isolation and management of resources and configurations specific to their needs. Since each Organization will receive its own Kubernetes Namespace within the Greenhouse cluster.

While Greenhouse is build on the idea of a self-service API and automation driven platform, the workflow to onboard an organization to Greenhouse involves reaching out to the Greenhouse administrators. This ensures all pre-requisites are met, the organization is configured correctly and the administrators of the Organization understand the platform capabilities.

Steps

1. IdP Group An IdP Group is required to configure the administrators of the organization. Onboarding without an Group is not possible, as this would leave the organization without any administrators having access. Please include the name of the IdP Group in the message to the Greenhouse team when signing up.

2. Identity Provider
   The authentication for the users belonging to your organization is based on the OpenID Connect (OIDC) standard.
   Please include the parameters for your OIDC provider in the message to the Greenhouse team when signing up.

3. Greenhouse organization
   A Greenhouse administrator applies the following configuration to the central Greenhouse cluster.
   Bear in mind that the name of the organization is immutable and will be part of all URLs.

   apiVersion: v1
   kind: Namespace
   metadata:
     name: my-organization
   ---
   apiVersion: v1
   kind: Secret
   metadata:
     name: oidc-config
     namespace: my-organization
   type: Opaque
   data:
     clientID: ...
     clientSecret: ...
   ---
   apiVersion: greenhouse.sap/v1alpha1
   kind: Organization
   metadata:
     name: my-organization
   spec:
     authentication:
       oidc:
         clientIDReference:
           key: clientID
           name: oidc-config
         clientSecretReference:
           key: clientSecret
           name: oidc-config
         issuer: https://...
       scim:
         baseURL: URL to the SCIM server.
         basicAuthUser:
           secret:
             name: Name of the secret in the same namespace.
             key: Key in the secret holding the user value.
         basicAuthPw:
           secret:
             name: Name of the secret in the same namespace.
             key: Key in the secret holding the password value.
     description: My new organization
     displayName: Short name of the organization
     mappedOrgAdminIdPGroup: Name of the group in the IDP that should be mapped to the organization admin role.
   

Setting up Team members synchronization with Greenhouse

Team members synchronization with Greenhouse requires access to SCIM API.

For the members to be reflected in a Team’s status, the created Organization needs to be configured with URL and credentials of the SCIM API. SCIM API is used to get members for teams in the organization based on the IDP groups set for teams.

IDP group for the organization admin team must be set to the mappedOrgAdminIdPGroup field in the Organization configuration. It is required for the synchronization to work. IDP groups for remaining teams in the organization should be set in their respective configurations - Team’s mappedIdpGroup field.

Next Steps

• Organization reference