https://cloudoperators.dev/Recent content on GreenhouseHugoen-ushttps://cloudoperators.dev/docs/reference/api/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/api/Packages: greenhouse.sap/v1alpha1 greenhouse.sap/v1alpha2 greenhouse.sap/v1alpha1 Resource Types: AuthType (string alias) (Appears on: SCIMConfig) AuthType defines the authentication method for SCIM API access. Authentication (Appears on: OrganizationSpec) Field Description oidc OIDCConfig OIDConfig configures the OIDC provider. scim SCIMConfig SCIMConfig configures the SCIM client. Catalog Catalog is the Schema for the catalogs API. Field Description metadata Kubernetes meta/v1.ObjectMeta Refer to the Kubernetes API documentation for the fields of the metadata field. spec CatalogSpec sourceshttps://cloudoperators.dev/docs/architecture/high-level/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/architecture/high-level/Greenhouse components --- title: Greenhouse High-Level Architecture --- flowchart LR kubectl[kubectl] dashboard[Greenhouse Dashboard] api[Greenhouse API endpoint] subgraph "Greenhouse Central Cluster" direction TB operator[Greenhouse Operators] end subgraph "Remote Cluster" direction TB rbac[Kubernetes RBAC] helmRelease[Helm Releases] end kubectl --> api dashboard --> api api --> operator operator --> rbac operator --> helmRelease From a high-level perspective, the Greenhouse platform consists of these main components: Greenhouse Central Cluster: The API Server of the central Greenhouse cluster serves as the API endpoint that acts as the primary interface for users to interact with the Greenhouse platform.https://cloudoperators.dev/docs/operations/playbooks/cluster/cluster-not-ready/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/operations/playbooks/cluster/cluster-not-ready/Alert Description This alert fires when a Greenhouse-managed cluster has not been ready for more than 15 minutes. What does this alert mean? The Greenhouse controller monitors the health of all registered clusters. When a cluster is not ready, it indicates that the Greenhouse operator cannot properly communicate with or manage resources on that cluster. This could be due to: Network connectivity issues between Greenhouse and the cluster Invalid or expired kubeconfig credentials The cluster API server being unavailable Insufficient permissions for Greenhouse to access the cluster Node issues preventing the cluster from being operational Diagnosis Get the Cluster Resource Retrieve the cluster resource to view its current status:https://cloudoperators.dev/docs/contribute/local-dev/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/contribute/local-dev/What is Greenhouse? Greenhouse is a Kubernetes operator build with Kubebuilder and a UI on top of the k8s API. It expands the Kubernetes API via CustomResourceDefinitions. The different aspects of the CRDs are reconciled by several controllers. It also acts as an admission webhook. The Greenhouse Dashboard is a UI acting on the k8s apiserver of the cluster Greenhouse is running in. The UI itself is a Juno application containing several micro frontends.https://cloudoperators.dev/docs/user-guides/cluster/onboarding/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/user-guides/cluster/onboarding/Content Overview Preparation Onboard After onboarding Troubleshooting This guides describes how to onboard an existing Kubernetes cluster to your Greenhouse organization. If you don’t have an organization yet please reach out to the Greenhouse administrators. While all members of an organization can see existing clusters, their management requires org-admin or cluster-admin privileges. See RBAC within the Organization namespace for details. :information_source: The UI is currently in development. For now this guide describes the onboarding workflow via command line.https://cloudoperators.dev/docs/operations/playbooks/operator/operator-reconcile-errors-high/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/operations/playbooks/operator/operator-reconcile-errors-high/Alert Description This alert fires when more than 10% of reconciling operations fail for a controller for 15 minutes. What does this alert mean? The Greenhouse operator uses controllers to manage various resources. When a controller’s reconciliation error rate exceeds 10%, it indicates systemic issues preventing the controller from properly managing its resources. This could be due to: API server connectivity issues Resource conflicts or invalid resource states Missing dependencies or referenced resources Permission issues preventing controller operations Resource exhaustion (memory, CPU) affecting controller performance Bugs in the controller logic Diagnosis Identify the Affected Controller The alert label controller identifies which controller is failing.https://cloudoperators.dev/docs/operations/playbooks/organization/organization-not-ready/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/operations/playbooks/organization/organization-not-ready/Alert Description This alert fires when a Greenhouse Organization has not been ready for more than 15 minutes. What does this alert mean? An Organization in Greenhouse represents a tenant and serves as the primary namespace for all resources belonging to that organization. When an Organization is not ready, it indicates that Greenhouse cannot properly initialize or manage the organization’s resources. This could be due to: Issues with the organization’s namespace creation or configuration RBAC setup failures IdP (Identity Provider) configuration problems Service proxy provisioning issues Default team role configuration problems Diagnosis Get the Organization Resource Retrieve the organization resource to view its current status:https://cloudoperators.dev/docs/getting-started/core-concepts/organizations/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/getting-started/core-concepts/organizations/What are Organizations? Organizations are the top-level entities in Greenhouse. Each Organization gets a dedicated Namespace, that contains all resources bound to the Organization. Greenhouse expects an Organization to provide its own Identity Provider and currently supports OIDC Identity Providers. Greenhouse also supports SCIM for syncing users and groups from an Identity Provider. See Creating an Organization for more details. Organization Namespace and Permissions The Organization’s Namespace in the Greenhouse cluster contains all resources bound to the Organization.https://cloudoperators.dev/docs/reference/components/organization/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/components/organization/An Organization is the top-level entity within Greenhouse. Each Organization represents a different tenant within Greenhouse and is provided with a dedicated Namespace in the Greenhouse cluster. Example Organization Spec apiVersion: greenhouse.sap/v1alpha1 kind: Organization metadata: name: example-organization spec: authentication: oidc: issuer: https://accounts.example.com clientId: example-client-id Writing an Organization Spec DisplayName .spec.displayName is a human-friendly name for the Organization. This field is optional; if not provided, it defaults to the value of metadata.https://cloudoperators.dev/docs/getting-started/overview/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/getting-started/overview/What is Greenhouse? Greenhouse is a cloud operations platform designed to streamline and simplify the management of a large-scale, distributed infrastructure. It offers a unified interface for organizations to manage various operational aspects efficiently and transparently and operate their cloud infrastructure in compliance with industry standards. The platform addresses common challenges such as the fragmentation of tools, visibility of application-specific permission concepts and the management of organizational groups. It also emphasizes the harmonization and standardization of authorization concepts to enhance security and scalability.https://cloudoperators.dev/docs/operations/playbooks/plugin/plugin-not-ready/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/operations/playbooks/plugin/plugin-not-ready/Alert Description This alert fires when a Plugin has not been ready for more than 15 minutes. What does this alert mean? A Plugin in Greenhouse represents an application or service deployed to a target cluster via Helm. When a Plugin is not ready, it indicates that the deployment or the workload resources are not functioning correctly. This could be due to: Helm chart deployment failures Missing or invalid PluginDefinition Cluster access issues Invalid plugin option values Workload resources not becoming ready (pods failing, etc.https://cloudoperators.dev/docs/operations/playbooks/proxy/proxy-request-errors-high/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/operations/playbooks/proxy/proxy-request-errors-high/Alert Description This alert fires when more than 10% of HTTP requests result in 4xx (excluding 401/403) or 5xx errors for a proxy service for 15 minutes. What does this alert mean? Greenhouse proxy services (like service-proxy, cors-proxy, idproxy) handle HTTP traffic for various purposes. High error rates indicate that requests are failing, which affects user experience and functionality. This could be due to: Backend services being unavailable or unhealthy Misconfigured routing or proxy rules Authentication/authorization issues (if 401/403 are included) Network connectivity problems to backend services Resource exhaustion in the proxy pod Invalid requests from clients Diagnosis Identify the Affected Proxy Service The alert label proxy identifies which proxy service has high error rates:https://cloudoperators.dev/docs/operations/playbooks/resource/resource-owned-by-label-missing/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/operations/playbooks/resource/resource-owned-by-label-missing/Alert Description This alert fires when resources exist without the required greenhouse.sap/owned-by label for 15 minutes. What does this alert mean? The greenhouse.sap/owned-by label is used to track resource ownership by Teams. This label should reference a Team with the greenhouse.sap/support-group=true label. Missing ownership labels make it difficult to: Track responsibility for resources Audit resource ownership Contact support teams for issues Enforce access control policies Diagnosis Identify the Affected Resource The alert provides:https://cloudoperators.dev/docs/operations/playbooks/team/team-membership-count-drop/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/operations/playbooks/team/team-membership-count-drop/Alert Description This alert fires when the number of members for a team has dropped by more than 5 in the last 5 minutes. What does this alert mean? This alert detects sudden drops in team membership that could indicate: Accidental bulk removal of team members in the IdP SCIM synchronization issues causing member data loss IdP group configuration changes Potential security incidents (unauthorized access removal) A drop of more than 5 members in 5 minutes is unusual and warrants investigation.https://cloudoperators.dev/docs/reference/components/cluster/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/components/cluster/A Cluster represents an external Kubernetes cluster that is managed by Greenhouse. Clusters are onboarded to an Organization and can be targeted by Plugins and PluginPresets to deploy infrastructure components. Example Cluster apiVersion: greenhouse.sap/v1alpha1 kind: Cluster metadata: name: example-cluster namespace: example-organization labels: metadata.greenhouse.sap/region: europe metadata.greenhouse.sap/environment: production spec: accessMode: direct Working with Clusters Setting Metadata Labels Cluster metadata is stored as Kubernetes resource labels with the metadata.greenhouse.sap/ prefix. Add or update metadata labels on an existing Cluster using kubectl:https://cloudoperators.dev/docs/operations/playbooks/cluster/cluster-token-expiry/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/operations/playbooks/cluster/cluster-token-expiry/Alert Description This alert fires when the kubeconfig token for a cluster will expire in less than 20 hours. What does this alert mean? Greenhouse has two ways of authenticating to Clusters: OIDC trust - Preferred method, credential-less authentication Initial kubeconfig - Traditional method using kubeconfig credentials This alert only fires when initially a kubeconfig was provided. Greenhouse will create a Service Account on the target Cluster and keep a kubeconfig with a token scoped to this SA on the Greenhouse Cluster.https://cloudoperators.dev/docs/contribute/plugins/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/contribute/plugins/What is a Plugin? A Plugin is a key component that provides additional features, functionalities and may add new tools or integrations to the Greenhouse project. They are developed de-centrally by the domain experts. A YAML specification outlines the components that are to be installed and describes mandatory and optional, instance-specific configuration values. It can consist of two main parts: Juno micro frontend This integrates with the Greenhouse dashboard, allowing users to interact with the Plugin’s features seamlessly within the Greenhouse UI.https://cloudoperators.dev/docs/operations/playbooks/operator/operator-reconcile-duration-higher-10min/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/operations/playbooks/operator/operator-reconcile-duration-higher-10min/Alert Description This alert fires when the average reconciliation duration exceeds 10 minutes for a controller for 15 minutes. What does this alert mean? Controllers should reconcile resources quickly. When reconciliation takes longer than 10 minutes on average, it indicates performance issues that can lead to delays in applying configuration changes and resource state updates. This could be due to: High number of resources being managed Slow external API calls (e.https://cloudoperators.dev/docs/operations/playbooks/plugin/plugin-constantly-failing/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/operations/playbooks/plugin/plugin-constantly-failing/Alert Description This alert fires when a Plugin reconciliation is constantly failing for 15 minutes. What does this alert mean? This alert indicates that the Greenhouse controller is repeatedly failing to reconcile the Plugin resource. Unlike a one-time failure, this suggests a persistent issue that prevents the Plugin from being properly managed. Common causes include: Invalid plugin option values that cannot be resolved Missing PluginDefinition reference Persistent Helm chart rendering or installation errors Invalid or missing secrets referenced in option values Cluster access issues that don’t resolve Configuration conflicts Diagnosis Get the Plugin Resource Retrieve the plugin resource to view its current status:https://cloudoperators.dev/docs/reference/components/plugindefinition/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/components/plugindefinition/A PluginDefinition brings either a UI application, a Helm chart deployment, or both, to the Greenhouse platform. The Helm chart for a PluginDefinition can be used to deploy infrastructure components to a Kubernetes cluster managed with Greenhouse. The PluginDefinition provides an opinionated way to configure, integrate and deploy these components with Greenhouse. Example PluginDefinition Spec apiVersion: greenhouse.sap/v1alpha1 kind: PluginDefinition metadata: name: alerts namespace: example-organization spec: description: The Alerts Plugin consists of both Prometheus Alertmanager and Supernova, the holistic alert management UI displayName: Alerts docsURL: https://cloudoperators.https://cloudoperators.dev/docs/architecture/product_design/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/architecture/product_design/Introduction Vision “Greenhouse is an extendable Platform that enables Organizations to operate their Infrastructure in a compliant, efficient and transparent manner” We want to build a Platform that is capable to integrate all the tools that are required to operate services in a cloud environment in a compliant, effective and transparent manner. Greenhouse aims to be the single stop for Operators of cloud-native infrastructure. The primary focus of Greenhouse is to provide a unified interface for all operational aspects and tools, providing a simple shared data model describing the support organization.https://cloudoperators.dev/docs/operations/playbooks/proxy/proxy-request-duration-high/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/operations/playbooks/proxy/proxy-request-duration-high/Alert Description This alert fires when the 90th percentile latency of a proxy service exceeds 500ms for 15 minutes. What does this alert mean? High latency in proxy services degrades user experience and can cause timeouts. When response times consistently exceed 500ms, it indicates performance issues that need investigation. This could be due to: Slow backend services Network latency to remote clusters or services Resource constraints on the proxy pod High traffic volume overwhelming the proxy Inefficient routing or processing logic DNS resolution delays Diagnosis Identify the Affected Proxy Service The alert label proxy identifies which proxy service has high latency:https://cloudoperators.dev/docs/user-guides/cluster/oidc_connectivity/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/user-guides/cluster/oidc_connectivity/Content Overview OIDC Overview Preparation Onboard Troubleshooting This guide describes how to onboard an existing Kubernetes cluster to your Greenhouse Organization with OIDC configuration. If you don’t have a Greenhouse Organization yet, please reach out to the Greenhouse administrators. While all members of an Organization can see existing Clusters, their management requires org-admin or cluster-admin privileges. See RBAC with the Organization namespace for details. :information_source: The UI is currently in development.https://cloudoperators.dev/docs/operations/playbooks/organization/scim-access-not-ready/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/operations/playbooks/organization/scim-access-not-ready/Alert Description This alert fires when the SCIM access for an organization is not ready for more than 15 minutes. What does this alert mean? SCIM (System for Cross-domain Identity Management) is used by Greenhouse to synchronize team members from external identity providers. When SCIM access is not ready, it indicates that Greenhouse cannot properly communicate with the SCIM API to fetch and synchronize user and group information. This could be due to:https://cloudoperators.dev/docs/operations/playbooks/team/team-role-binding-not-ready/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/operations/playbooks/team/team-role-binding-not-ready/Alert Description This alert fires when a TeamRoleBinding has not been ready for more than 15 minutes. What does this alert mean? A TeamRoleBinding in Greenhouse maps a Team to a TeamRole on one or more clusters. When a TeamRoleBinding is not ready, it means that the RBAC resources (RoleBindings or ClusterRoleBindings) could not be properly created on the target clusters, preventing team members from accessing the clusters with the intended permissions.https://cloudoperators.dev/docs/getting-started/core-concepts/teams/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/getting-started/core-concepts/teams/What are Teams? Teams in a Greenhouse Organization are used to group users by group claims on the token provided by the upstream identity provider (IdP). This can be used, for example, for organizational management access and permission management identifying Ownership of resources The Greenhouse UI is showing the members of a Team. Team RBAC TeamRoles and TeamRoleBindings provide a mechanism to control the permissions of Teams to onboarded Clusters of an Organization.https://cloudoperators.dev/docs/user-guides/plugin/plugin-tests/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/user-guides/plugin/plugin-tests/Overview Plugin Testing Requirements All Plugins contributed to Plugin-Extensions repository should include comprehensive Helm Chart Tests using the bats/bats-detik testing framework. This ensures our Plugins are robust, deployable, and catch potential issues early in the development cycle. What is bats/bats-detik? The bats/bats-detik framework simplifies end-to-end (e2e) Testing in Kubernetes. It combines the Bash Automated Testing System (bats) with Kubernetes-specific assertions (detik). This allows you to write test cases using natural language-like syntax, making your tests easier to read and maintain.https://cloudoperators.dev/docs/architecture/monitoring/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/architecture/monitoring/The main terminologies used in this document can be found in core-concepts. Introduction to Observability Observability in software and infrastructure is essential for operating a complex cloud environment. High-quality observability will enable teams to: Detect and troubleshoot issues quickly, Maintain performance and reliability, Make data-driven improvements. Core Signals The three key signals of observability are metrics, logs, and traces, each providing unique insights contributing to a comprehensive view of a system’s health.https://cloudoperators.dev/docs/operations/playbooks/cluster/cluster-kubernetes-version-out-of-maintenance/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/operations/playbooks/cluster/cluster-kubernetes-version-out-of-maintenance/Alert Description This alert fires when a cluster is running a Kubernetes version that is out of maintenance. What does this alert mean? Kubernetes versions have a limited support lifecycle. When a version goes out of maintenance, it no longer receives security patches or bug fixes. Running clusters on unsupported versions poses security risks and may lead to compatibility issues with newer features and tools. This alert fires when a cluster is detected running Kubernetes version which are out of the official Kubernetes maintenance window.https://cloudoperators.dev/docs/getting-started/core-concepts/clusters/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/getting-started/core-concepts/clusters/What are Clusters? In the context of Greenhouse a Cluster represents a Kubernetes cluster that is onboarded to Greenhouse. Onboarded in this context means that Greenhouse can handle the management of role-based access control (RBAC) and the provisioning of operating tools (e.g. logging, monitoring, ingress etc.). The Greenhouse dashboard provides an overview of all onboarded clusters. Throughout Greenhouse the reference to a Cluster is used to target it for configuration and deployments.https://cloudoperators.dev/docs/contribute/new-controller/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/contribute/new-controller/Bootstrap a new Controller Before getting started please make sure you have read the contribution guidelines. Greenhouse is build using Kubebuilder as the framework for Kubernetes controllers. To create a new controller, you can use the kubebuilder CLI tool. This project was generated with Kubebuilder v4. It’s necessary to create a symlink from cmd/greenhouse/main.go to cmd/main.go in to run the Kubebuider scaffolding commands. ln $(pwd)/cmd/greenhouse/main.go $(pwd)/cmd/main.go To create a new controller, run the following command:https://cloudoperators.dev/docs/operations/playbooks/proxy/idproxy-errors-high/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/operations/playbooks/proxy/idproxy-errors-high/Alert Description This alert fires when more than 10% of IDProxy operations result in errors for 15 minutes. What does this alert mean? The IDProxy handles authentication and identity proxying for Greenhouse. High error rates indicate authentication or identity management issues that prevent users from accessing resources. This could be due to: Issues with the identity provider (IdP) integration OIDC/OAuth configuration problems Network connectivity to the IdP Invalid or expired tokens Misconfigured callback URLs or client credentials Resource constraints on the IDProxy pod Diagnosis Check IDProxy Metrics Access the Prometheus instance monitoring your Greenhouse cluster and query the IDProxy request metrics using the following PromQL queries:https://cloudoperators.dev/docs/getting-started/install/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/getting-started/install/This section provides a step-by-step guide to install Greenhouse on a Gardener shoot cluster. Prerequisites Before you start the installation, make sure you have the following prerequisites: Helm & Kubernetes CLI OAuth2/OpenID provider (see Authentik) Gardener Shoot Cluster configured to use the OIDC provider nginx-ingress deployed in the cluster Installation To install Greenhouse on your Gardener shoot cluster, follow these steps: Create a values file called values.yaml with the following content:https://cloudoperators.dev/docs/user-guides/cluster/offboarding/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/user-guides/cluster/offboarding/Content Overview Pre-requisites Off-boarding Troubleshooting This guides describes how to off-board an existing Kubernetes cluster in your Greenhouse organization. While all members of an organization can see existing clusters, their management requires org-admin or cluster-admin privileges. See RBAC with the Organization namespace for details. :information_source: The UI is currently in development. For now this guide describes the onboarding workflow via command line. Pre-requisites Off-boarding a Cluster in Greenhouse requires authenticating to the greenhouse cluster via kubeconfig file:https://cloudoperators.dev/docs/getting-started/operations/processes/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/getting-started/operations/processes/Operational Processes in Greenhouse Greenhouse provides a couple of predefined operational processes. Operational processes facilitated via Greenhouse heavily rely on the Ownership principle. It is used to route operational tasks to Support Groups. Examples for these operational tasks are: Alert routing based on metrics Lifecycle management of k8s Clusters Security posture and vulnerability patch management Secret rotation and management Labels Used Greenhouse focuses on labels in three different places: On resources (e.https://cloudoperators.dev/docs/operations/playbooks/operator/operator-workqueue-not-drained/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/operations/playbooks/operator/operator-workqueue-not-drained/Alert Description This alert fires when a controller’s workqueue backlog is not getting drained for 15 minutes. What does this alert mean? Each controller uses a workqueue to process reconciliation requests. When the workqueue depth continues to grow rather than being drained, it indicates that the controller cannot keep up with the incoming reconciliation requests. This could be due to: High rate of resource changes overwhelming the controller Slow reconciliation operations (see also OperatorReconcileDurationHigher10Min) Controller pod being resource-constrained Deadlocks or stuck reconciliation loops External systems being slow or unavailable Diagnosis Identify the Affected Controller The alert label controller identifies the controller workqueue that is not draining.https://cloudoperators.dev/docs/getting-started/operations/ownership/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/getting-started/operations/ownership/What is Ownership within Greenhouse Ownership in Greenhouse is the combination of two of the core features: User and Organization management via Teams Deployment of resources (Plugins, TeamRoleBindings) to remote Clusters Greenhouse provides a 1:1 relationship between a Team and PluginPresets Plugins Clusters TeamRoleBindings Secrets Within the context of Greenhouse this relationship is called Ownership. Why Ownership of Resources Operational processes facilitated via Greenhouse rely on Ownership: By identifying the owner of a resource it is possible to route operational tasks on the resource to the owner.https://cloudoperators.dev/docs/user-guides/plugin/plugin-deployment/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/user-guides/plugin/plugin-deployment/Before you begin This guides describes how to configure and deploy a Greenhouse plugin. apiVersion: greenhouse.sap/v1alpha1 kind: Plugin metadata: name: kube-monitoring-martin namespace: <organization namespace> # same namespace in remote cluster for resources spec: clusterName: <name of the remote cluster > disabled: false displayName: <any human readable name> pluginDefinition: <pluginDefinition name> releaseNamespace: <namespace> # namespace in remote cluster where the plugin is deployed releaseName: <helm release name> # name of the helm release that will be created optionValues: - name: <from the plugin options> value: <from the plugin options> - .https://cloudoperators.dev/docs/reference/components/pluginpreset/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/components/pluginpreset/A PluginPreset is used to configure Plugins for a set of Clusters. This allows administrators to define standard configurations for Clusters in the same environment or with similar requirements. Greenhouse will create Plugins based on the PluginPreset for each Cluster that matches the specified selector. Example PluginPreset Spec apiVersion: greenhouse.sap/v1alpha1 kind: PluginPreset metadata: name: perses-preset namespace: example-organization spec: clusterOptionOverrides: - clusterName: example-cluster overrides: - name: perses.serviceMonitor.selfMonitor value: true - name: perses.https://cloudoperators.dev/docs/user-guides/organization/registry-overrides/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/user-guides/organization/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.https://cloudoperators.dev/docs/getting-started/operations/authorization-webhook/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/getting-started/operations/authorization-webhook/Overview The Greenhouse Authorization Webhook enforces fine-grained access control on Greenhouse resources based on Team ownership. The webhook checks if a user’s support-group claims match the greenhouse.sap/owned-by label on resources before granting access. This enables Teams to have elevated permissions on resources they own, while maintaining visibility across the Organization. Why This Exists Greenhouse uses a single namespace per Organization for all resources. While this simplifies management, it requires a mechanism to allow Teams to manage their own resources without unrestricted access to resources owned by other Teams.https://cloudoperators.dev/docs/user-guides/plugin/plugin-management/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/user-guides/plugin/plugin-management/Managing Plugins for multiple clusters This guide describes how to configure and deploy a Greenhouse Plugin with the same configuration into multiple clusters. The PluginPreset resource is used to create and deploy Plugins with a the identical configuration into multiple clusters. The list of clusters the Plugins will be deployed to is determind by a LabelSelector. As a result, whenever a cluster, that matches the ClusterSelector is onboarded or offboarded, the Controller for the PluginPresets will take care of the Plugin Lifecycle.https://cloudoperators.dev/docs/getting-started/core-concepts/plugins/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/getting-started/core-concepts/plugins/What are PluginDefinitions and Plugins? PluginDefinitons and Plugins are the Greenhouse way to extend the core functionality with domain specific features. PluginDefinitions, as the name suggests, are the definition of a Plugin, whereas a Plugin is a concrete instance of a PluginDefinition that is deployed to a Cluster. The PluginDefinitions are shared between all Organizations in Greenhouse. A PluginDefinition can include a frontend, that is displayed in the Greenhouse dashboard and/or a backend component.https://cloudoperators.dev/docs/reference/components/plugin/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/components/plugin/A Plugin is an instance of a PluginDefinition and is used to deploy infrastructure components such as observability, compliance or system components to a Kubernetes cluster managed with Greenhouse. A Plugin provides the specific configuration for deploying the Helm chart associated with the referenced PluginDefinition to a specific cluster. Example Plugin Spec apiVersion: greenhouse.sap/v1alpha1 kind: Plugin metadata: name: alerts-plugin namespace: example-organization spec: clusterName: example-cluster displayName: Example Alerts Plugin optionValues: - name: image.https://cloudoperators.dev/docs/operations/playbooks/operator/webhook-latency-high/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/operations/playbooks/operator/webhook-latency-high/Alert Description This alert fires when the 90th percentile latency of a Greenhouse webhook exceeds 200ms for 15 minutes. What does this alert mean? Webhooks are admission controllers that validate or mutate resources before they are persisted to etcd. High webhook latency can slow down all API requests for the resources the webhook handles, affecting user operations and controller reconciliations. This could be due to: Complex validation or mutation logic External API calls from the webhook (e.https://cloudoperators.dev/docs/reference/components/catalog/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/components/catalog/A Catalog is a collection of PluginDefinitions that can be made available to Organizations within Greenhouse. Catalogs allow organization admins to manage the lifecycle of PluginDefinitions by controlling which version of a PluginDefinition is deployed to their cluster fleet. The Catalog API is currently in alpha and is still under active development and is subjected to change. Example The following is an example of a Greenhouse Catalog that reconciles the PluginDefinition manifests stored in a Git Repository.https://cloudoperators.dev/docs/user-guides/plugin/metadata-expressions/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/user-guides/plugin/metadata-expressions/Overview Greenhouse allows you to define metadata labels on Clusters and use them in PluginPreset configurations through CEL (Common Expression Language) expressions. This enables dynamic configuration of Plugins based on cluster-specific attributes like region, environment, or any custom metadata. For information on setting metadata labels on Clusters, see Setting Metadata Labels. Using Expressions with PluginPresets Expressions are particularly powerful with PluginPresets, allowing you to deploy Plugins to multiple clusters with cluster-specific configurations:https://cloudoperators.dev/docs/user-guides/plugin/catalog/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/user-guides/plugin/catalog/Before you begin This guides describes how to explore the catalog of Greenhouse PluginDefinitions. While all members of an organization can see the Plugin catalog, enabling, disabling and configuration PluginDefinitions for an organization requires organization admin privileges. Exploring the PluginDefinition catalog The PluginDefinition resource describes the backend and frontend components as well as mandatory configuration options of a Greenhouse extension. While the PluginDefinition catalog is managed by the Greenhouse administrators and the respective domain experts, administrators of an organization can configure and tailor Plugins to their specific requirements.https://cloudoperators.dev/docs/operations/playbooks/operator/webhook-errors-high/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/operations/playbooks/operator/webhook-errors-high/Alert Description This alert fires when more than 10% of webhook operations fail for a webhook for 15 minutes. What does this alert mean? Webhooks validate or mutate resources before they are persisted. When a webhook’s error rate exceeds 10%, it indicates that many API requests for the affected resources are being rejected or failing. This could be due to: Invalid resource configurations being submitted External dependencies being unavailable (e.g., clusters, teams, secrets) Permission issues in webhook operations Bugs in the webhook logic Network issues preventing webhook from accessing required resources Diagnosis Identify the Affected Webhook and Resource The alert label webhook identifies which webhook has high error rates.https://cloudoperators.dev/docs/reference/catalog/alerts/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/catalog/alerts/Learn more about the alerts plugin. Use it to activate Prometheus alert management for your Greenhouse organisation. The main terminologies used in this document can be found in core-concepts. Overview This Plugin includes a preconfigured Prometheus Alertmanager, which is deployed and managed via the Prometheus Operator, and Supernova, an advanced user interface for Prometheus Alertmanager. Certificates are automatically generated to enable sending alerts from Prometheus to Alertmanager. These alerts can too be sent as Slack notifications with a provided set of notification templates.https://cloudoperators.dev/docs/reference/catalog/audit-logs/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/catalog/audit-logs/Learn more about the Audit Logs Plugin. Use it to enable the ingestion, collection and export of telemetry signals (logs and metrics) for your Greenhouse cluster. The main terminologies used in this document can be found in core-concepts. Overview OpenTelemetry is an observability framework and toolkit for creating and managing telemetry data such as metrics, logs and traces. Unlike other observability tools, OpenTelemetry is vendor and tool agnostic, meaning it can be used with a variety of observability backends, including open source tools such as OpenSearch and Prometheus.https://cloudoperators.dev/docs/reference/catalog/blackbox-exporter/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/catalog/blackbox-exporter/This Plugin provides the Blackbox Exporter which allows blackbox probing of endpoints over HTTP, HTTPS, DNS, TCP, ICMP and gRPC.https://cloudoperators.dev/docs/reference/catalog/cert-manager/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/catalog/cert-manager/This Plugin provides the cert-manager to automate the management of TLS certificates. Configuration This section highlights configuration of selected Plugin features. All available configuration options are described in the plugin.yaml. Ingress shim An Ingress resource in Kubernetes configures external access to services in a Kubernetes cluster. Securing ingress resources with TLS certificates is a common use-case and the cert-manager can be configured to handle these via the ingress-shim component. It can be enabled by deploying an issuer in your organization and setting the following options on this plugin.https://cloudoperators.dev/docs/user-guides/organization/creation/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/user-guides/organization/creation/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.https://cloudoperators.dev/docs/reference/catalog/doop/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/catalog/doop/This directory contains the Greenhouse plugin for the Decentralized Observer of Policies (DOOP). DOOP To perform automatic validations on Kubernetes objects, we run a deployment of OPA Gatekeeper in each cluster. This dashboard aggregates all policy violations reported by those Gatekeeper instances.https://cloudoperators.dev/docs/reference/catalog/disco/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/catalog/disco/This Plugin provides the Designate Ingress CNAME operator (DISCO) to automate management of DNS entries in OpenStack Designate for Ingress and Services in Kubernetes.https://cloudoperators.dev/docs/reference/catalog/digicert-issuer/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/catalog/digicert-issuer/This Plugin provides the digicert-issuer, an external Issuer extending the cert-manager with the DigiCert cert-central API.https://cloudoperators.dev/docs/reference/catalog/doop-api/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/catalog/doop-api/Backend API for the DOOP (Decentralized Observer of Policies) system. Reads Gatekeeper audit reports aggregated by per-cluster doop-analyzer pods from OpenStack Swift and serves them to the doop UI plugin.https://cloudoperators.dev/docs/reference/catalog/external-dns/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/catalog/external-dns/This Plugin provides the external DNS operator which synchronizes exposed Kubernetes Services, Ingresses, Gateway HttpRoutes, TLSRoutes with DNS providers. Refer to chart documentation for available configuration options.https://cloudoperators.dev/docs/reference/catalog/external-secrets/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/catalog/external-secrets/This Plugin provides the External Secrets Operator (ESO) to synchronize secrets from external secret providers (e.g. AWS Secrets Manager, Vault, Azure Key Vault, GCP Secret Manager) into Kubernetes Secret resources. Configuration This section highlights configuration of selected Plugin features. Refer to the upstream chart documentation for all available configuration options. Option Type Default Description installCRDs bool true Install and upgrade CRDs through the Helm chart replicaCount int 1 Replicas for the controller serviceMonitor.https://cloudoperators.dev/docs/reference/catalog/gatekeeper-doop/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/catalog/gatekeeper-doop/Per-cluster components of DOOP for OPA Gatekeeper. Runs alongside the gatekeeper operator on every managed cluster: doop-analyzer subscribes to Gatekeeper audit reports, deduplicates violations via merging rules, and uploads the aggregate to an OpenStack Swift container that the central doop-api plugin then serves. doop-image-checker is an HTTP service called by Rego policies (via http.send) to check container image vulnerability and provenance against a container registry that exposes the required metadata. helm-manifest-parser is an HTTP service that decodes Helm release Secret blobs into JSON so policies can reason about Helm-managed resources.https://cloudoperators.dev/docs/reference/catalog/ingress-nginx/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/catalog/ingress-nginx/This plugin contains the ingress NGINX controller. Example To instantiate the plugin create a Plugin like: apiVersion: greenhouse.sap/v1alpha1 kind: Plugin metadata: name: ingress-nginx spec: pluginDefinition: ingress-nginx-v4.4.0 values: - name: controller.service.loadBalancerIP value: 1.2.3.4https://cloudoperators.dev/docs/reference/catalog/kafka/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/catalog/kafka/Kafka Plugin The Kafka plugin sets up an Apache Kafka environment using the Strimzi Kafka Operator, automating deployment, provisioning, management, and orchestration of Kafka clusters with KRaft mode (without ZooKeeper). Overview Apache Kafka is a distributed event streaming platform designed for high-throughput, fault-tolerant, real-time data processing. The Strimzi Kafka Operator simplifies the management of Kafka clusters on Kubernetes. Components included in this Plugin: Strimzi Kafka Operator Apache Kafka Cluster Management (KRaft mode) Kafka Exporter for Metrics (optional) Cruise Control for Cluster Optimization (optional) Entity Operator for Topic and User Management Note More configurations will be added over time, and contributions of custom configurations are highly appreciated.https://cloudoperators.dev/docs/reference/catalog/k8s-gateway-api/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/catalog/k8s-gateway-api/This plugin installs the Kubernetes Gateway API CRDs (standard channel) into a cluster. The Gateway API is the next-generation Kubernetes ingress, load balancing, and service mesh API. It is designed to be expressive, extensible, and role-oriented. Example To instantiate the plugin create a Plugin like: apiVersion: greenhouse.sap/v1alpha1 kind: Plugin metadata: name: k8s-gateway-api spec: pluginDefinitionRef: name: k8s-gateway-apihttps://cloudoperators.dev/docs/reference/catalog/kube-monitoring/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/catalog/kube-monitoring/Learn more about the kube-monitoring plugin. Use it to activate Kubernetes monitoring for your Greenhouse cluster. The main terminologies used in this document can be found in core-concepts. Overview Observability is often required for operation and automation of service offerings. To get the insights provided by an application and the container runtime environment, you need telemetry data in the form of metrics or logs sent to backends such as Prometheus or OpenSearch.https://cloudoperators.dev/docs/reference/catalog/logs/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/catalog/logs/Learn more about the Logs Plugin. Use it to enable the ingestion, collection and export of telemetry signals (logs and metrics) for your Greenhouse cluster. The main terminologies used in this document can be found in core-concepts. Overview OpenTelemetry is an observability framework and toolkit for creating and managing telemetry data such as metrics, logs and traces. Unlike other observability tools, OpenTelemetry is vendor and tool agnostic, meaning it can be used with a variety of observability backends, including open source tools such as OpenSearch and Prometheus.https://cloudoperators.dev/docs/reference/catalog/logshipper/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/catalog/logshipper/This Plugin is intended for shipping container and systemd logs to an Elasticsearch/ OpenSearch cluster. It uses fluentbit to collect logs. The default configuration can be found under chart/templates/fluent-bit-configmap.yaml. Components included in this Plugin: fluentbit Owner @ivogoman Parameters Name Description Value fluent-bit.parser Parser used for container logs. [docker|cri] labels “cri” fluent-bit.backend.opensearch.host Host for the Elastic/OpenSearch HTTP Input fluent-bit.backend.opensearch.port Port for the Elastic/OpenSearch HTTP Input fluent-bit.backend.opensearch.http_user Username for the Elastic/OpenSearch HTTP Input fluent-bit.https://cloudoperators.dev/docs/reference/catalog/netapp-monitoring/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/catalog/netapp-monitoring/Learn more about the netapp-monitoring plugin. Use it to deploy Harvest for monitoring NetApp storage filers via Prometheus metrics. Overview This plugin deploys a monitoring stack for NetApp storage systems using NetApp Harvest. Harvest collects performance, capacity, and health metrics from ONTAP systems and exposes them via a Prometheus exporter. The chart includes a service discovery component (netappsd) that automatically discovers NetApp filers from Netbox and spawns Harvest instances to collect metrics.https://cloudoperators.dev/docs/reference/catalog/nvidia-gpu-operator/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/catalog/nvidia-gpu-operator/This Plugin provides the NVIDIA GPU Operator which automates the management of NVIDIA software components needed to provision GPUs in Kubernetes clusters. The bundled node-feature-discovery subchart is enabled by default and can be disabled via nfd.enabled if NFD is already installed separately.https://cloudoperators.dev/docs/reference/catalog/gatekeeper/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/catalog/gatekeeper/This Plugin provides OPA Gatekeeper, a policy controller for Kubernetes based on the Open Policy Agent constraint framework. Constraints Only the operator is deployed. No ConstraintTemplate or Constraint resources are bundled. Constraints can be applied separately, or installed via the gatekeeper-config PluginDefinition (planned). Enforcement Enforcement mode is set per Constraint via spec.enforcementAction. Valid values: dryrun (log only), warn (return warning), deny (block). Configuration See plugindefinition.yaml for available options. Webhook scoping By default the validating webhook intercepts all API groups (*).https://cloudoperators.dev/docs/reference/catalog/gatekeeper-config/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/catalog/gatekeeper-config/Deploys OPA Gatekeeper ConstraintTemplates and Constraints for Kubernetes admission control. Provides a library of universal admission policies that can be enabled and tuned per cluster. Requires the OPA Gatekeeper PluginDefinition to be installed on the cluster. Policies Policy Description highCpuRequests Flags workloads that request more than maxCpu cores in total across containers and initContainers. unmanagedPods Flags Pods that have no ownerReference (i.e. not managed by a Deployment, DaemonSet, etc.). forbiddenClusterwideObjects Restricts which MutatingWebhookConfiguration and ValidatingWebhookConfiguration objects may exist on the cluster via an allowlist of webhook names.https://cloudoperators.dev/docs/reference/catalog/opensearch/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/catalog/opensearch/OpenSearch Plugin The OpenSearch plugin sets up an OpenSearch environment using the OpenSearch Operator, automating deployment, provisioning, management, and orchestration of OpenSearch clusters and dashboards. It functions as the backend for logs gathered by collectors such as OpenTelemetry collectors, enabling storage and visualization of logs for Greenhouse-onboarded Kubernetes clusters. The main terminologies used in this document can be found in core-concepts. Overview OpenSearch is a distributed search and analytics engine designed for real-time log and event data analysis.https://cloudoperators.dev/docs/reference/catalog/perses/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/catalog/perses/Table of Contents Table of Contents Overview Disclaimer Quick Start Configuration Create a custom dashboard Manage Resources with ConfigMaps Recommended folder structure Manage Resources with OCI Artifacts Learn more about the Perses Plugin. Use it to visualize Prometheus/Thanos metrics for your Greenhouse remote cluster. The main terminologies used in this document can be found in core-concepts. Overview Observability is often required for the operation and automation of service offerings. Perses is a CNCF project and it aims to become an open-standard for dashboards and visualization.https://cloudoperators.dev/docs/reference/catalog/prometheus/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/catalog/prometheus/Learn more about the prometheus plugin. Use it to deploy a single Prometheus for your Greenhouse cluster. The main terminologies used in this document can be found in core-concepts. Overview Observability is often required for operation and automation of service offerings. To get the insights provided by an application and the container runtime environment, you need telemetry data in the form of metrics or logs sent to backends such as Prometheus or OpenSearch.https://cloudoperators.dev/docs/user-guides/team/rbac/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/user-guides/team/rbac/Greenhouse Team RBAC user guide Role-Based Access Control (RBAC) in Greenhouse allows Organization administrators to manage the access of Teams on Clusters. TeamRole and TeamRoleBindings are used to manage the RBAC on remote Clusters. These two Custom Resource Definitions allow for fine-grained control over the permissions of each Team within each Cluster and Namespace. Contents Before you begin Overview Defining TeamRoles Example Seeded default TeamRoles Defining TeamRoleBindings Assigning a TeamRole to a single Team on a Cluster Assigning a TeamRole to multiple Teams on a Cluster Assigning TeamRoles to Teams on multiple Clusters Aggregating TeamRoles Migrating from the deprecated teamRef field Updating TeamRoleBindings Before you begin This guide is intended for users who want to manage Role-Based Access Control (RBAC) for Teams on remote clusters managed by Greenhouse.https://cloudoperators.dev/docs/reference/catalog/reloader/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/catalog/reloader/This Plugin provides the Reloader to automate triggering rollouts of workloads whenever referenced Secrets or ConfigMaps are updated.https://cloudoperators.dev/docs/reference/catalog/repo-guard/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/catalog/repo-guard/Repo Guard automates GitHub organization management using Kubernetes Custom Resources (CRDs).https://cloudoperators.dev/docs/reference/catalog/exposed-services/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/catalog/exposed-services/This Plugin is just providing a simple exposed service for manual testing. By adding the following label or annotation to a service it will become accessible from the central greenhouse system via a service proxy: Label (legacy, transitioning to annotation): greenhouse.sap/expose: "true" Annotation: greenhouse.sap/expose: "true" During the transition period, both label and annotation are supported. This plugin create an nginx deployment with an exposed service for testing. Configuration Specific port By default expose would always use the first port.https://cloudoperators.dev/docs/reference/catalog/shoot-grafter/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/catalog/shoot-grafter/Example Plugin apiVersion: greenhouse.sap/v1alpha1 kind: Plugin metadata: name: shoot-grafter spec: displayName: Shoot Grafter optionValues: - name: image.registry value: ghcr.io/cloudoperators pluginDefinitionRef: kind: ClusterPluginDefinition name: shoot-grafter releaseName: shoot-grafter releaseNamespace: greenhouse # shoot-grafter is a ClusterPluginDefinition Read up the shoot-grafter documentation.https://cloudoperators.dev/docs/reference/catalog/supernova/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/catalog/supernova/Learn more about the Supernova Plugin, an advanced user interface for Prometheus Alertmanager. The main terminologies used in this document can be found in core-concepts. Overview This plugin provides the stand alone UI application Supernova and needs an Prometheus Alertmanager to be queried. Provisioning of the Alertmanager is not part of this plugin. Supernova This Plugin usually is deployed on the greenhouse central cluster, one per greenhouse organization. Disclaimer This is not meant to be a comprehensive package that covers all scenarios.https://cloudoperators.dev/docs/user-guides/team/create/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/user-guides/team/create/Before you begin This guides describes how to create a team in your Greenhouse organization. While all members of an organization can see existing teams, their management requires organization admin privileges. Creating a team The team resource is used to structure members of your organization and assign fine-grained access and permission levels. Each Team must be backed by a group in the identity provider (IdP) of the Organization. IdP group should be set on the mappedIdPGroup field in Team configuration.https://cloudoperators.dev/docs/user-guides/team/authorization/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/user-guides/team/authorization/Overview Greenhouse resources (Plugin, PluginPreset, Cluster, TeamRoleBinding) can be owned by a Team. Team members receive elevated access (get, update, patch, delete) on resources their Team owns — without requiring organization-wide admin permissions. This is enforced by the Authorization Webhook, which checks that the requesting user’s IdP token contains a support-group: claim matching the resource’s greenhouse.sap/owned-by label. Prerequisites Before your Team can use elevated access, two things must be in place:https://cloudoperators.dev/docs/reference/components/teamrolebinding/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/components/teamrolebinding/A TeamRoleBinding assigns a TeamRole to one or more Teams (and/or individual usernames) for a set of Clusters and optionally a set of Namespaces. The Greenhouse controller translates a TeamRoleBinding into native Kubernetes rbacv1 resources on each targeted remote cluster. Example TeamRoleBinding Spec apiVersion: greenhouse.sap/v1alpha2 kind: TeamRoleBinding metadata: name: example-team-pod-read namespace: example-organization spec: teamRoleRef: pod-read teamRefs: - example-team - dev-team clusterSelector: labelSelector: matchLabels: environment: production namespaces: - monitoring - logging createNamespaces: false Writing a TeamRoleBinding Spec .https://cloudoperators.dev/docs/reference/catalog/thanos/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/catalog/thanos/Learn more about the Thanos Plugin. Use it to enable extended metrics retention and querying across Prometheus servers and Greenhouse clusters. The main terminologies used in this document can be found in core-concepts. Overview Thanos is a set of components that can be used to extend the storage and retrieval of metrics in Prometheus. It allows you to store metrics in a remote object store and query them across multiple Prometheus servers and Greenhouse clusters.https://cloudoperators.dev/docs/reference/catalog/trust-manager/Mon, 01 Jan 0001 00:00:00 +0000https://cloudoperators.dev/docs/reference/catalog/trust-manager/This Plugin provides trust-manager to automate the management and distribution of trust bundles across Kubernetes clusters. Trust-manager is a Kubernetes operator that distributes trust bundles (CA certificates) to workloads running in your cluster. It works alongside cert-manager and enables you to manage CA trust stores declaratively. Prerequisites cert-manager must be installed on the target cluster before deploying this plugin. Trust-manager depends on cert-manager for its webhook certificates. You can install it using the cert-manager Greenhouse plugin.