mirror of
https://gitlab.opencode.de/bmi/opendesk/deployment/opendesk.git
synced 2025-12-06 23:41:43 +01:00
Compare commits
7 Commits
rfischer/b
...
b1-boekhor
| Author | SHA1 | Date | |
|---|---|---|---|
|
195a9eae55 | ||
|
|
8867d1b204 | ||
|
|
cca755d4af | ||
|
|
2423ac2de6 | ||
|
|
09a233511e | ||
|
|
7d101b18d7 | ||
|
|
10f1ced37d |
@@ -767,17 +767,33 @@ import-default-accounts:
|
||||
- "echo \"Starting default account import for ${DOMAIN}\""
|
||||
- "cd /app"
|
||||
- |
|
||||
./user_import_udm_rest_api.py \
|
||||
--import_domain ${DOMAIN} \
|
||||
--udm_api_password ${DEFAULT_ADMINISTRATOR_PASSWORD} \
|
||||
--set_default_password ${DEFAULT_ACCOUNTS_PASSWORD} \
|
||||
--import_filename ./template.ods \
|
||||
--admin_enable_fileshare True \
|
||||
--admin_enable_knowledgemanagement True \
|
||||
--admin_enable_projectmanagement True \
|
||||
--create_admin_accounts True \
|
||||
--create_maildomains True \
|
||||
--verify_certificate False
|
||||
set +e
|
||||
success=0
|
||||
for i in {1..5}; do
|
||||
echo "Attempt $i/5..."
|
||||
./user_import_udm_rest_api.py \
|
||||
--import_domain ${DOMAIN} \
|
||||
--udm_api_password ${DEFAULT_ADMINISTRATOR_PASSWORD} \
|
||||
--set_default_password ${DEFAULT_ACCOUNTS_PASSWORD} \
|
||||
--import_filename ./template.ods \
|
||||
--admin_enable_fileshare True \
|
||||
--admin_enable_knowledgemanagement True \
|
||||
--admin_enable_projectmanagement True \
|
||||
--create_admin_accounts True \
|
||||
--create_maildomains True \
|
||||
--verify_certificate False
|
||||
if [ $? -eq 0 ]; then
|
||||
echo "Script succeeded on attempt $i."
|
||||
success=1
|
||||
break
|
||||
fi
|
||||
echo "Script failed. Waiting 60 seconds before retry..."
|
||||
sleep 60
|
||||
done
|
||||
if [ "$success" -ne 1 ]; then
|
||||
echo "Script failed after 5 attempts."
|
||||
exit 1
|
||||
fi
|
||||
|
||||
run-tests:
|
||||
stage: "post-execute"
|
||||
|
||||
@@ -14,7 +14,7 @@
|
||||
* **open-xchange:** Template SASL security options ([684c6d4](https://gitlab.opencode.de/bmi/opendesk/deployment/opendesk/commit/684c6d4f29dd447872ebe582eef43c04034896f7))
|
||||
* **open-xchange:** Update Dovecot configuration based on supplier's best practise review ([850761e](https://gitlab.opencode.de/bmi/opendesk/deployment/opendesk/commit/850761e0475b2f281fb23f6972d5c74fbdaa3a61))
|
||||
* **opendesk-static-files:** [[#260](https://gitlab.opencode.de/bmi/opendesk/deployment/opendesk/issues/260)] Fix doublette creation of configmap `data` keys when the same file is referenced multiple times for a component ([b5a76be](https://gitlab.opencode.de/bmi/opendesk/deployment/opendesk/commit/b5a76bea57ef7b136c54d1bc95c40f0a0c3f9716))
|
||||
* **openproject:** Update from 16.1.0 to 16.1.1 ([62fae99](https://gitlab.opencode.de/bmi/opendesk/deployment/opendesk/commit/62fae9976a731c00700d56ce8fab198bb2531d20))
|
||||
* **openproject:** Update from 16.6.0 to 16.6.1 ([62fae99](https://gitlab.opencode.de/bmi/opendesk/deployment/opendesk/commit/62fae9976a731c00700d56ce8fab198bb2531d20))
|
||||
* **xwiki:** Update XWiki from 17.4.4 to 17.4.7 ([02a3b77](https://gitlab.opencode.de/bmi/opendesk/deployment/opendesk/commit/02a3b7711490394690df70ca92bab58b253e34f5))
|
||||
|
||||
|
||||
|
||||
@@ -32,53 +32,43 @@ SPDX-License-Identifier: Apache-2.0
|
||||
|
||||
# Preamble / Scope
|
||||
|
||||
This document lays out the requirements for all components of the openDesk (called "component" in the following).
|
||||
This document lays out the requirements for open-source products that should become part of openDesk.
|
||||
|
||||
This document can be used to assess the status and possible gaps for a component, which might itself be the basis for a decision if the component should be integrated into openDesk by working on closing the identified gaps.
|
||||
As this is a comprehensive set of requirements most new components will not adhere to all of them.
|
||||
|
||||
This document can be used to assess the status and possible gaps for a component which might itself be the basis for a decision if a component should be integrated into openDesk by working on closing the identified gaps.
|
||||
|
||||
> [!note]
|
||||
> Even an already integrated application might not adhere to all aspects of the documented requirements yet.
|
||||
> Closing the gaps for existing applications therefore is an openDesk priority.
|
||||
|
||||
> [!note]
|
||||
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
|
||||
> NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
|
||||
> "OPTIONAL" in this document are to be interpreted as described in
|
||||
> [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119).
|
||||
> - MUST(NOT): These requirements are hard requirements and must be fulfilled. If technically possible they can be considered hard-blocking qualitygates that could prevent a new components artifact/container from being deployed.
|
||||
> - SHOULD(NOT): These requirements don't need to be fulfilled but might be the future. Any given MUST-Requirement was a SHOULD-Requirement for at minimum 90 days and can only be bumped as an openDesk RFC.
|
||||
|
||||
|
||||
# Software bill of materials (SBOMs)
|
||||
|
||||
openDesk pürovides in-depth SBOM for container images. Those SBOMs are Scoped on a per-container basis. SBOMs SHOULD contain all software components present in the final image, even when obfuscated through static linking. False-Positive-Components are expected.
|
||||
|
||||
Components MUST provide artifact and source code SBOMs in a standardized manner, ideally in the current [CycloneDX](https://cyclonedx.org/tool-center/) format ( 1.7 at time of writing ). This is explicitly supported by openCode's [DevGuard](https://devguard.opencode.de/) toolchain.
|
||||
|
||||
openDesk is looking into options for in-depth SBOM creation first for container images and later for source code. It is still expected by the suppliers to provide artifact and source code SBOMs in a standardized manner, ideally in the openCode preferred [SPDX 2.2.1](https://spdx.org/rdf/ontology/spdx-2-2-1/) format.
|
||||
|
||||
**Reference:** https://gitlab.opencode.de/bmi/opendesk/deployment/SBOM/-/tree/main/sboms/0.5.74
|
||||
|
||||
## Artifact SBOMs
|
||||
|
||||
There are various free tools like [syft](https://github.com/anchore/syft) available to generate SBOMs for container images. Components MUST provide cryptographically signed artifact SBOMs for all container images delivered to be integrated into openDesk.
|
||||
There are various free tools like [syft](https://github.com/anchore/syft) available to generate SBOMs for container images. It is expected that this kind of artifact SBOMs is provided (and signed) for all containers delivered to be integrated into openDesk.
|
||||
|
||||
**Reference:** As part of [openDesk's standard CI](https://gitlab.opencode.de/bmi/opendesk/tooling/gitlab-config) a container image SBOM is derived from the container's content and gets signed. Both artifacts (SBOM and signature) are placed next to the image in the related registry ([e.g.](https://gitlab.opencode.de/bmi/opendesk/components/platform-development/images/semantic-release/container_registry/827)).
|
||||
|
||||
## Source code SBOMs
|
||||
|
||||
Today's software development platforms like GitLab or GitHub provide dependency list/graph features that are the basis for your source code SBOMs. These features are usually based on analysis of language-specific package manager dependency definition files. As part of a component supplier's software development process, it is expected that source code SBOMs are at least created on the level of the already defined software dependencies within the source code tree of the component.
|
||||
Today's software development platforms like GitLab or GitHub provide dependency list/graph features that are the basis for your source code SBOMs. These features are usually based on analysis of language-specific package manager dependency definition files. As part of a supplier's software development process, it is expected that source code SBOMs are at least created on the level of the already defined software dependencies within the source code tree of the component.
|
||||
|
||||
**Reference:** Currently we do not have source code SBOMs in place.
|
||||
|
||||
# License compliance
|
||||
|
||||
All parts of openDesk Community Edition MUST be open source (ToDo: add reference to definition). Source code MUST BE published or MUST BE publishable on openCode.
|
||||
All parts of openDesk Community Edition must be open source with source code (also) published or at least publishable on openCode.
|
||||
|
||||
openCode provides some boundaries when it comes to open source license compliance openDesk has to adhere to:
|
||||
|
||||
- The components must be published under a license listed in the [openCode license allow list](https://opencode.de/de/wissen/rechtssichere-nutzung/open-source-lizenzen).
|
||||
- Delivered artifacts (container images) must contain only components licensed under the aforementioned allow list. A container must not contain any artifact using a license from the [openCode license block list](https://opencode.de/de/wissen/rechtssichere-nutzung/open-source-lizenzen#3.-Negativliste-aller-nicht-freigegebenen-Lizenzen).
|
||||
|
||||
[ToDo: we should make this a markdown?]
|
||||
Deviations from the above requirements must be documented in the openDesk license deviation report.
|
||||
|
||||
**Reference:** https://gitlab.opencode.de/bmi/opendesk/deployment/SBOM/-/blob/main/sboms/openDesk%20Deviation%20Report-0.5.74.md
|
||||
@@ -87,8 +77,6 @@ Deviations from the above requirements must be documented in the openDesk licens
|
||||
|
||||
ZenDiS plans to provide secured key storage as a service on openCode.
|
||||
|
||||
[ToDo: update to v1.2?]
|
||||
|
||||
openDesk is going to implement [SLSA v1.0](https://slsa.dev/spec/v1.0/).
|
||||
|
||||
The minimum requirement for all of openDesk's functional components is that all component artifacts (i.e. container images, Helm charts) are signed and their signature can be verified based on the ZenDiS-provided secure key store.
|
||||
@@ -99,8 +87,6 @@ The minimum requirement for all of openDesk's functional components is that all
|
||||
|
||||
Note: openDesk is operated as a Kubernetes (K8s) workload.
|
||||
|
||||
[ToDo: shouldn't we link to these as well: IG BvC, DVS, Pod Security Standards]
|
||||
|
||||
openDesk applications should adhere to best practices for K8s application/container design. While there are dozens of documents about these best practices please use them as references:
|
||||
- https://cloud.google.com/architecture/best-practices-for-building-containers
|
||||
- https://cloud.google.com/architecture/best-practices-for-operating-containers
|
||||
@@ -127,8 +113,6 @@ You will find below some of the most common best practice requirements, some of
|
||||
|
||||
# Security
|
||||
|
||||
[ToDo: shouldn't we move this up to container arch. basics?]
|
||||
|
||||
openDesk should be compliant with the "Deutsche Verwaltungscloud Strategie" (DVS). While this is a moving target it references some already established standards like the BSI's [IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/IT-Grundschutz-Kompendium/it-grundschutz-kompendium_node.html) and [C5](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nach-Angriffszielen/Cloud-Computing/Kriterienkatalog-C5/C5_AktuelleVersion/C5_AktuelleVersion_node.html). These standards address hundreds of requirements which are published at the given links. So here's just a summary to understand the approach of the broadest requirements from IT-Grundschutz.
|
||||
|
||||
**Reference:** [Deutsche Verwaltungscloud-Strategie – Rahmenwerk der Zielarchitektur](https://www.cio.bund.de/SharedDocs/downloads/Webs/CIO/DE/cio-bund/steuerung-it-bund/beschluesse_cio-board/2023_11_Beschluss_CIO_Board_DVS_Rahmenwerk_Anlage.pdf)
|
||||
@@ -157,7 +141,7 @@ We are aware that IT-Grundschutz is a complex topic and are working towards a st
|
||||
|
||||
# Accessibility
|
||||
|
||||
Accessibility is a key requirement for software that is being used in the public sector. Therefore the products of the suppliers MUST adhere to the relevant standards.
|
||||
Accessibility is a key requirement for software that is being used in the public sector. Therefore the products of the suppliers are expected to adhere to the relevant standards.
|
||||
|
||||
Please find more context about the topic on the [website of the German CIO](https://www.cio.bund.de/Webs/CIO/DE/digitaler-wandel/it-barrierefreiheit/vorgaben-und-richtlinien/vorgaben-und-richtlinien-node.html) followed by a more detailed look at the actual accessibility standard [WCAG 2.1](https://www.barrierefreiheit-dienstekonsolidierung.bund.de/Webs/PB/DE/gesetze-und-richtlinien/wcag/wcag-artikel.html).
|
||||
|
||||
@@ -171,7 +155,7 @@ Each vendor must provide a certificate that their product - or the parts of the
|
||||
|
||||
# Data protection
|
||||
|
||||
Each component MUST be able to operate according to the [EU's General Data Protection Regulation (GDPR)](https://gdpr.eu/). This requires some key messages to be answered when it comes to personal data[^1]:
|
||||
Each component must be able to operate according to the [EU's General Data Protection Regulation (GDPR)](https://gdpr.eu/). This requires some key messages to be answered when it comes to personal data[^1]:
|
||||
|
||||
- Who are the affected data subjects?
|
||||
- What personal data (attributes) from the subjects is being processed?
|
||||
@@ -217,15 +201,15 @@ Applications can access the IAM's LDAP to access all data necessary for managing
|
||||
|
||||
### Push: Provisioning
|
||||
|
||||
Some applications require active provisioning of the centrally maintained IAM data. As the actual provisioning is part of the openDesk provisioning framework, it is necessary to define the ULC flow regarding its different states to get a matching provisioning connector implemented. This is done collaboratively between the supplier and openDesk product management.
|
||||
Some applications require active provisioning of the centrally maintained IAM data. As the actual provisioning is part of the openDesk provisioning framework it is necessary to define the ULC flow regarding its different states to get a matching provisioning connector implemented. This is done collaboratively between the supplier and openDesk product management.
|
||||
|
||||
**Reference:** New applications will make use of the [provisioning framework](https://gitlab.opencode.de/bmi/opendesk/component-code/crossfunctional/univention/ums-provisioning-api). At the moment to only active (push) provisioned component is OX AppSuite fed by the [OX-connector](https://github.com/univention/ox-connector/tree/ucs5.0).
|
||||
|
||||
## Authentication
|
||||
|
||||
The central IdP ensures the single sign-on and logout workflows. openDesk consistently uses [Open ID Connect](https://openid.net/). It can be configured to provide additional user information from the IAM if required by a component.
|
||||
The central IdP ensures the single sign-on and logout workflows. As standard openDesk uses [Open ID Connect](https://openid.net/). It can be configured to provide additional user information from the IAM when required by a component.
|
||||
|
||||
The following configuration is REQUIRED regarding the OIDC support in a component, besides the actual login flow:
|
||||
Minimum requirements regarding the OIDC support in an application besides the actual login flow:
|
||||
|
||||
- Back-channel logout: [OIDC Back-Channel Logout](https://openid.net/specs/openid-connect-backchannel-1_0.html) must be supported by the components unless there is a significant reason why it technically cannot be supported, in that case [OIDC Front-Channel Logout](https://openid.net/specs/openid-connect-frontchannel-1_0.html) is the alternative.
|
||||
- IdP Session Refresh: Ensure that your application regularly checks the IdP session for its validity and invalidates the local session when there is no longer an IdP session.
|
||||
@@ -234,12 +218,10 @@ The following configuration is REQUIRED regarding the OIDC support in a componen
|
||||
|
||||
## Top bar
|
||||
|
||||
The top bar of all applications SHOULD provide a common UX.
|
||||
The top bar of all applications should provide a common UX.
|
||||
|
||||
### Look and feel
|
||||
|
||||
[ToDo: make req. clear according to RFC2119]
|
||||
|
||||
The current status is subject to review, but the basics will most likely stay the same. Ensure that the top bar can be customized (or adheres to a given openDesk standard) in various settings:
|
||||
|
||||
- Size (height) of the bar.
|
||||
@@ -254,11 +236,9 @@ The current status is subject to review, but the basics will most likely stay th
|
||||
|
||||
### Central navigation
|
||||
|
||||
[ToDo: make req. clear according to RFC2119]
|
||||
From the top bar, the user can access the central navigation. A menu that gets its contents from the portal, rending the categories and (sub-)applications available to the logged-in user.
|
||||
|
||||
From the top bar, the user can access the central navigation: A menu that gets its contents from the portal components, rendering the categories and (sub-)applications available to the logged-in user.
|
||||
|
||||
When implementing the central navigation into an application, there are two options to access the user's data from the portal:
|
||||
When implementing the central navigation into an application there are two options to access the user's data from the portal:
|
||||
|
||||
- Frontend-based: Issuing an IFrame-based silent login against the intercom service (ICS) to get a session with the ICS, followed by a request for the JSON containing the user's central navigation contents through the ICS.
|
||||
- Backend-based: Requesting the JSON using a backend call to the portal providing the user's name and a shared secret.
|
||||
@@ -267,7 +247,7 @@ When implementing the central navigation into an application, there are two opti
|
||||
|
||||
## Functional administration
|
||||
|
||||
While applications usually support technical and functional administration, the technical part SHOULD be in the responsibility of the operator and is usually done at (re)deployment time. Therefore, the administrative tasks within an application should be limited to functional administration.
|
||||
While applications usually support technical and functional administration the technical part should be in the responsibility of the operator and is usually done at (re)deployment time. Therefore the administrative tasks within an application should be limited to functional administration.
|
||||
|
||||
Example for "technical administration":
|
||||
- Configuring the SMTP relay for an application to send out emails.
|
||||
@@ -279,17 +259,17 @@ Example of "functional administration":
|
||||
|
||||
## Theming
|
||||
|
||||
Theming MUST be controlled with the deployment and affect all components that support branding options.
|
||||
Theming should be controlled with the deployment and affect all components that support branding options.
|
||||
|
||||
**Reference:** https://gitlab.opencode.de/bmi/opendesk/deployment/opendesk/-/issues/27
|
||||
|
||||
## Central user profile
|
||||
|
||||
The user profile is maintained centrally, therefore the components SHOULD make use of that central data and not allow local editing of the data within the application, except for data that is required by the component and that cannot be provided by the central IAM.
|
||||
The user profile is maintained centrally, therefore the applications should make use of that central data and not allow local editing of the data within the application except for data that is required by the application and cannot be provided by the central IAM.
|
||||
|
||||
The data can still be rendered but MUST NOT be tampered with in any way within an openDesk application outside of the IAM, as it would either cause inconsistent data within openDesk or the changed data being overwritten, which is at least unexpected behaviour from the user's perspective.
|
||||
The data can still be rendered but must not be tampered with in any way within an openDesk application outside of the IAM, as it would either cause inconsistent data within the platform or the changed data being overwritten, which is at least unexpected by the user.
|
||||
|
||||
The user's preferred language and theme (light/dark) are also selected in the IAM's portal and the setting SHOULD be respected in all components.
|
||||
The user's preferred language and theme (light/dark) are also selected in the IAM's portal and the setting should be respected in all applications.
|
||||
|
||||
**Reference:** No reference yet.
|
||||
|
||||
|
||||
@@ -65,7 +65,7 @@ For your convenience, we recommend creating a `*.domain.tld` A-Record for your c
|
||||
| Record name | Type | Value | Additional information |
|
||||
|-------------------------------|------|----------------------------------------------------|-------------------------------------------------------------------|
|
||||
| *.domain.tld | A | IPv4 address of your Ingress Controller | |
|
||||
| *.domain.tld | AAAA | IPv6 address of your Ingress Controller | |
|
||||
| *.domain.tld | AAAA | IPv6 address of your Ingress Controller | Optional |
|
||||
| mail.domain.tld | A | IPv4 address of your postfix NodePort/LoadBalancer | Optional, mail should directly be delivered to openDesk's Postfix |
|
||||
| mail.domain.tld | AAAA | IPv6 address of your postfix NodePort/LoadBalancer | Optional, mail should directly be delivered to openDesk's Postfix |
|
||||
| domain.tld | MX | `10 mail.domain.tld` | |
|
||||
|
||||
@@ -13,8 +13,10 @@ SPDX-License-Identifier: Apache-2.0
|
||||
* [Versions ≥ v1.11.0](#versions--v1110)
|
||||
* [Pre-upgrade to versions ≥ v1.11.0](#pre-upgrade-to-versions--v1110)
|
||||
* [Helmfile new option: Annotations for external services (Dovecot, Jitsi JVB, Postfix)](#helmfile-new-option-annotations-for-external-services-dovecot-jitsi-jvb-postfix)
|
||||
* [Helmfile new secret: `secrets.nextcloud.statusPassword`](#helmfile-new-secret-secretsnextcloudstatuspassword)
|
||||
* [Versions ≥ v1.10.0](#versions--v1100)
|
||||
* [Pre-upgrade to versions ≥ v1.10.0](#pre-upgrade-to-versions--v1100)
|
||||
* [Deployment cleanup: Collabora Controller](#deployment-cleanup-collabora-controller)
|
||||
* [Helmfile new secret: `secrets.nubus.ldapSearch.postfix`](#helmfile-new-secret-secretsnubusldapsearchpostfix)
|
||||
* [Helmfile new secret: `secrets.doveocot.sharedMailboxesMasterPassword`](#helmfile-new-secret-secretsdoveocotsharedmailboxesmasterpassword)
|
||||
* [New Helmfile default: Nubus provisioning debug container no longer deployed](#new-helmfile-default-nubus-provisioning-debug-container-no-longer-deployed)
|
||||
@@ -213,10 +215,43 @@ Setting service annotation by `annotations.openxchangePostfix.service` applied t
|
||||
and external service. This key now only sets annotations for the internal service. If you want to set
|
||||
annotations for the external service use the newly introduced key `annotations.openxchangePostfix.serviceExternal`.
|
||||
|
||||
#### Helmfile new secret: `secrets.nextcloud.statusPassword`
|
||||
|
||||
**Target group:** All existing deployments that use self-defined secrets and have deployed Nextcloud.
|
||||
|
||||
Access to Nextcloud's `/status.php` requires now BasicAuth. The related password is set in
|
||||
[`secrets.yaml.gotmpl`](../helmfile/environments/default/secrets.yaml.gotmpl) by the key
|
||||
`secrets.nextcloud.statusPassword`.
|
||||
|
||||
If you define your own secrets, please ensure that you provide a value for this secret, otherwise it will
|
||||
be derived from the `MASTER_PASSWORD`.
|
||||
|
||||
> [!note]
|
||||
> The username for the BasicAuth is hardcoded to "status-access".
|
||||
|
||||
## Versions ≥ v1.10.0
|
||||
|
||||
### Pre-upgrade to versions ≥ v1.10.0
|
||||
|
||||
#### Deployment cleanup: Collabora Controller
|
||||
|
||||
**Target group:** Existing openDesk Enterprise deployments using Collabora Controller. Actually only long running
|
||||
deployments are affected, but following the instructions won't hurt.
|
||||
|
||||
As per upstream release notes for [Collabora Online Controller 1.1.4](https://www.collaboraonline.com/cool-controller-release-notes/)
|
||||
you have to remove the existing leases of the Controller. You can do so by setting `<your_namespace>` and executing
|
||||
the commands below.
|
||||
|
||||
```shell
|
||||
export NAMESPACE=<your_namespace>
|
||||
export COLLABORA_CONTROLLER_DEPLOYMENT_NAME=collabora-controller-cool-controller
|
||||
kubectl -n ${NAMESPACE} scale deployment/${COLLABORA_CONTROLLER_DEPLOYMENT_NAME} --replicas=0
|
||||
kubectl -n ${NAMESPACE} delete -n collabora leases.coordination.k8s.io collabora-online
|
||||
```
|
||||
|
||||
> [!note]
|
||||
> The Collabora Online Controller is not scaled up again, as this would happen as part of the upgrade deployment.
|
||||
|
||||
#### Helmfile new secret: `secrets.nubus.ldapSearch.postfix`
|
||||
|
||||
**Target group:** All existing deployments that use self-defined secrets.
|
||||
|
||||
@@ -23,8 +23,7 @@ openDesk includes integration with Prometheus-based monitoring.
|
||||
|
||||
Together with [kube-prometheus-stack](https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack), you can easily leverage the full potential of the open-source cloud-native observability stack.
|
||||
|
||||
Before enabling the following options, you need to install the respective custom resource definitions (CRDs) from the kube-prometheus-stack
|
||||
repository or Prometheus operator.
|
||||
Before enabling the following options, you need to install the respective custom resource definitions (CRDs) from the kube-prometheus-stack repository which should at least include the Prometheus Operator.
|
||||
|
||||
# Defaults
|
||||
|
||||
@@ -33,14 +32,16 @@ All configurable options and their defaults can be found in
|
||||
|
||||
# Metrics
|
||||
|
||||
To deploy `podMonitor` and `serviceMonitor` custom resources, enable it by:
|
||||
To deploy `podMonitor` and `serviceMonitor` custom resources, enable them by:
|
||||
|
||||
```yaml
|
||||
prometheus:
|
||||
serviceMonitors:
|
||||
enabled: true
|
||||
podMonitors:
|
||||
enabled: true
|
||||
monitoring:
|
||||
prometheus:
|
||||
serviceMonitors:
|
||||
enabled: true
|
||||
podMonitors:
|
||||
enabled: true
|
||||
```
|
||||
```
|
||||
|
||||
# Alerts
|
||||
@@ -51,19 +52,23 @@ Some of these are created by our partners while others are defined in [opendesk-
|
||||
All alert rules are deployed as [PrometheusRule](https://prometheus-operator.dev/docs/api-reference/api/#monitoring.coreos.com/v1.PrometheusRule) and can be enabled like this:
|
||||
|
||||
```yaml
|
||||
prometheus:
|
||||
prometheusRules:
|
||||
enabled: true
|
||||
monitoring:
|
||||
prometheus:
|
||||
prometheusRules:
|
||||
enabled: true
|
||||
```
|
||||
|
||||
# Dashboards for Grafana
|
||||
|
||||
To deploy optional Grafana dashboards with ConfigMaps, enable the functionality with:
|
||||
If your Grafana instance is deployed via kube-prometheus-stack, or you have deployed the [Sidecar for datasources](https://github.com/grafana/helm-charts/blob/main/charts/grafana/README.md#sidecar-for-datasources), openDesk can make dashboards available via ConfigMap resources.
|
||||
|
||||
Enable the functionality with the following snippet:
|
||||
|
||||
```yaml
|
||||
grafana:
|
||||
dashboards:
|
||||
enabled: true
|
||||
monitoring:
|
||||
grafana:
|
||||
dashboards:
|
||||
enabled: true
|
||||
```
|
||||
|
||||
Please find further details in the [related Helm chart](https://gitlab.opencode.de/bmi/opendesk/components/platform-development/charts/opendesk-dashboards).
|
||||
|
||||
@@ -29,14 +29,14 @@ openDesk is a Kubernetes-only solution and requires an existing Kubernetes (K8s)
|
||||
- K8s cluster >= v1.24, [CNCF Certified Kubernetes distribution](https://www.cncf.io/certification/software-conformance/)
|
||||
- Domain and DNS Service
|
||||
- Ingress controller (Ingress NGINX) >= [4.11.5/1.11.5](https://github.com/kubernetes/ingress-nginx/releases)
|
||||
- [Helm](https://helm.sh/) >= v3.17.3, but not v3.18.0[^1]
|
||||
- [Helm](https://helm.sh/) >= v3.17.3 (but not v3.18.0[^1]) and < v4[^2],
|
||||
- [Helmfile](https://helmfile.readthedocs.io/en/latest/) >= v1.0.0
|
||||
- [HelmDiff](https://github.com/databus23/helm-diff) >= v3.11.0
|
||||
- Volume provisioner supporting RWO (read-write-once)[^2]
|
||||
- Volume provisioner supporting RWO (read-write-once)[^3]
|
||||
- Certificate handling with [cert-manager](https://cert-manager.io/)
|
||||
|
||||
**Additional openDesk Enterprise requirements**
|
||||
- [OpenKruise](https://openkruise.io/)[^3] >= v1.6
|
||||
- [OpenKruise](https://openkruise.io/)[^4] >= v1.6
|
||||
|
||||
# Hardware
|
||||
|
||||
@@ -138,8 +138,11 @@ Helmfile requires [HelmDiff](https://github.com/databus23/helm-diff) to compare
|
||||
|
||||
# Footnotes
|
||||
|
||||
[^1]: Due to a [Helm bug](https://github.com/helm/helm/issues/30890) Helm 3.18.0 is not supported.
|
||||
[^1]: Due to a [Helm bug](https://github.com/helm/helm/issues/30890) Helm v3.18.0 is not supported.
|
||||
|
||||
[^2]: Due to [restrictions on Kubernetes `emptyDir`](https://github.com/kubernetes/kubernetes/pull/130277) you need a volume provisioner that has sticky bit support, otherwise the OpenProject seeder job will fail. E.g. the `local-path-provisioner` does not have sticky bit support.
|
||||
[^2]: Helm v4 introduced stricter flag grouping that is not yet supported by the helmdiff plugin.
|
||||
|
||||
[^3]: Due to [restrictions on Kubernetes `emptyDir`](https://github.com/kubernetes/kubernetes/pull/130277) you need a volume provisioner that has sticky bit support, otherwise the OpenProject seeder job will fail. E.g. the `local-path-provisioner` does not have sticky bit support.
|
||||
|
||||
[^4]: Required for Dovecot Pro as part of openDesk Enterprise Edition.
|
||||
|
||||
[^3]: Required for Dovecot Pro as part of openDesk Enterprise Edition.
|
||||
|
||||
@@ -118,6 +118,10 @@ aio:
|
||||
value: {{ .Values.databases.nextcloud.password | quote }}
|
||||
{{- end }}
|
||||
trustedProxy: {{ join " " .Values.cluster.networking.cidr | quote }}
|
||||
status:
|
||||
password:
|
||||
value: {{ .Values.secrets.nextcloud.statusPassword | quote }}
|
||||
|
||||
containerSecurityContext:
|
||||
allowPrivilegeEscalation: false
|
||||
capabilities:
|
||||
|
||||
@@ -33,6 +33,9 @@ config:
|
||||
value: "nextcloud"
|
||||
password:
|
||||
value: {{ .Values.secrets.nextcloud.adminPassword | quote }}
|
||||
status:
|
||||
password:
|
||||
value: {{ .Values.secrets.nextcloud.statusPassword | quote }}
|
||||
|
||||
containerSecurityContext:
|
||||
allowPrivilegeEscalation: false
|
||||
|
||||
@@ -13,7 +13,7 @@ images:
|
||||
nextcloud:
|
||||
registry: "registry.opencode.de"
|
||||
repository: "zendis/opendesk-enterprise/components/supplier/nextcloud/images/opendesk-nextcloud"
|
||||
tag: "1.6.11@sha256:79bab3b5745eb2c0fdd5a8858d277495deb7f6e43b42c7046d5bfbee039aed0a"
|
||||
tag: "1.7.1@sha256:aa91feaa89989178d859f21bb25633ef07facea19ac3ef696186256492a13b17"
|
||||
openxchangeCoreMW:
|
||||
registry: "registry.opencode.de"
|
||||
repository: "zendis/opendesk-enterprise/components/supplier/open-xchange/images-mirror/middleware-public-sector-pro"
|
||||
|
||||
@@ -249,7 +249,7 @@ charts:
|
||||
registry: "registry.opencode.de"
|
||||
repository: "bmi/opendesk/components/platform-development/charts/opendesk-nextcloud"
|
||||
name: "opendesk-nextcloud"
|
||||
version: "4.4.4"
|
||||
version: "4.5.0"
|
||||
verify: true
|
||||
nextcloudManagement:
|
||||
# providerCategory: "Platform"
|
||||
@@ -259,7 +259,7 @@ charts:
|
||||
registry: "registry.opencode.de"
|
||||
repository: "bmi/opendesk/components/platform-development/charts/opendesk-nextcloud"
|
||||
name: "opendesk-nextcloud-management"
|
||||
version: "4.4.4"
|
||||
version: "4.5.0"
|
||||
verify: true
|
||||
nextcloudNotifyPush:
|
||||
# providerCategory: "Platform"
|
||||
@@ -269,7 +269,7 @@ charts:
|
||||
registry: "registry.opencode.de"
|
||||
repository: "bmi/opendesk/components/platform-development/charts/opendesk-nextcloud"
|
||||
name: "opendesk-nextcloud-notifypush"
|
||||
version: "4.4.4"
|
||||
version: "4.5.0"
|
||||
verify: true
|
||||
nginx:
|
||||
# providerCategory: "Community"
|
||||
@@ -383,7 +383,7 @@ charts:
|
||||
registry: "registry.opencode.de"
|
||||
repository: "bmi/opendesk/components/platform-development/charts/opendesk-openproject-bootstrap"
|
||||
name: "opendesk-openproject-bootstrap"
|
||||
version: "2.2.0"
|
||||
version: "2.3.0"
|
||||
verify: true
|
||||
otterize:
|
||||
# providerCategory: "Platform"
|
||||
|
||||
@@ -330,7 +330,7 @@ images:
|
||||
# upstreamRepository: "bmi/opendesk/components/platform-development/images/opendesk-nextcloud"
|
||||
registry: "registry.opencode.de"
|
||||
repository: "bmi/opendesk/components/platform-development/images/opendesk-nextcloud"
|
||||
tag: "2.10.12@sha256:8a4cd73fdceb1da2c58a22a85d605eba575a2b1487e3927ab1971c9f1120549a"
|
||||
tag: "2.11.0@sha256:481e83fb913c98d2ede8ae734f406ac5c12f805093af0a34cb9c86eeaa56bc01"
|
||||
nextcloudExporter:
|
||||
# providerCategory: "Platform"
|
||||
# providerResponsible: "openDesk"
|
||||
@@ -770,7 +770,7 @@ images:
|
||||
# upstreamRepository: "bmi/opendesk/components/platform-development/images/opendesk-openproject-bootstrap"
|
||||
registry: "registry.opencode.de"
|
||||
repository: "bmi/opendesk/components/platform-development/images/opendesk-openproject-bootstrap"
|
||||
tag: "1.1.4@sha256:2fd97a316114428849aaeef87fb8755274e675830088a93afcafac91bb048d1d"
|
||||
tag: "1.2.0@sha256:7d2ab97a8cd17aa2c12a6d613044c848edf0371974662390eb08c197aa12b84a"
|
||||
openprojectDbInit:
|
||||
# providerCategory: "Community"
|
||||
# providerResponsible: "OpenProject"
|
||||
|
||||
@@ -101,6 +101,7 @@ secrets:
|
||||
nextcloud:
|
||||
adminPassword: {{ derivePassword 1 "long" (env "MASTER_PASSWORD" | default "sovereign-workplace") "nextcloud" "nextcloud_admin_user" | sha1sum | quote }}
|
||||
metricsToken: {{ derivePassword 1 "long" (env "MASTER_PASSWORD" | default "sovereign-workplace") "nextcloud" "metricsToken" | sha1sum | quote }}
|
||||
statusPassword: {{ derivePassword 1 "medium" (env "MASTER_PASSWORD" | default "sovereign-workplace") "nextcloud" "nextcloud_status_user" | sha1sum | quote }}
|
||||
openproject:
|
||||
adminPassword: {{ derivePassword 1 "long" (env "MASTER_PASSWORD" | default "sovereign-workplace") "openproject" "openproject_admin_user" | sha1sum | quote }}
|
||||
apiAdminUsername: {{ derivePassword 1 "long" (env "MASTER_PASSWORD" | default "sovereign-workplace") "openproject" "openproject_api_admin_username" | sha1sum | quote }}
|
||||
|
||||
Reference in New Issue
Block a user