Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Deliver up-to-date CA certificates to ExApps without rebuilding their images

Offen
  • Stimmt etwas nicht?
#1,038 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 3 Tagen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
30/100
Issue-Typ
Feature
Klarheit
Muss geklärt werden
Aktivitätsstatus
Aktiv
Tech-Stack
docker, kubernetes, php
Bereich
backend-api-design, infrastructure, security

Rechercherichtung

Beginne damit, die bestehende CA-Auslieferung rund um ICertificateManager::getAbsoluteBundlePath() und den Einstiegspunkt /k8s/exapp/install_certificates nachzuverfolgen, und vergleiche anschließend das Verhalten von Docker, Kubernetes und dem manuellen Daemon. Überprüfe den Ablauf von /heartbeat und /init, den NPA_NC_CERT-Vertrag von nc_py_api und die Diagnosen von Test Deploy. Als erledigt gilt eine festgelegte backendübergreifende Lösung, die Aktualisierung, gehärtete Umgebungen, Client-Kompatibilität und die Aufteilung der Arbeit mit HaRP abdeckt.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

deploy discussion enhancement

Problem

An ExApp trusts whatever CA certificates were baked into its image on the day the image was built. Public CAs keep introducing new roots, and admins use private PKIs, so over time an ExApp image starts rejecting perfectly valid certificates of the Nextcloud instance it has to call back.

The typical symptom: the ExApp container starts, AppAPI reaches it (/heartbeat and /init answer 200), but the ExApp's own request to Nextcloud fails with CERTIFICATE_VERIFY_FAILED (unable to get local issuer certificate or self-signed certificate in certificate chain). The deploy then hangs at the init step. For the admin this is hard to read, because the instance certificate is valid in every browser.

"Test Deploy" is hit first, since it is the first thing an admin runs, and its image is only rebuilt manually. Rebuilding the image fixes it for a while (nextcloud/test-deploy#44), but that does not scale: every ExApp image has the same problem, and we cannot rebuild and re-release all of them each time a CA ships a new root.

What happens today

  • Docker and HaRP (Docker) daemons: at deploy time AppAPI reads the Nextcloud CA bundle (ICertificateManager::getAbsoluteBundlePath(), i.e. the bundle shipped with the server plus everything imported with occ security:certificates:import), copies the certificates into the container and runs update-ca-certificates / update-ca-trust there (introduced for #411). This works, with limits:
    • it runs only on deploy and update, so certificates imported later do not reach ExApps that are already running;
    • it needs a supported OS, the update tool in the image, a writable root filesystem and root inside the container;
    • it only helps clients that read the OS trust store. Clients with their own bundle (certifi based ones, Node.js, Java) ignore it.
  • Kubernetes daemon: AppAPI sends the same bundle to HaRP, but /k8s/exapp/install_certificates is a no-op and nothing is mounted into the ExApp pod. An ExApp on Kubernetes only ever has the CA store of its image, so neither newer public roots nor a private CA can be delivered at all. Exec-based installation would not be a good fit there anyway (read-only root filesystems, non-root policies).
  • Manual daemons: nothing is delivered, which is fine, the developer owns that environment.

Goal

Collect ideas for a way to hand ExApps an up-to-date set of trusted CAs from the Nextcloud side, so that:

  • a valid instance certificate works without rebuilding any ExApp image,
  • certificates imported into Nextcloud reach ExApps on all deploy backends, including Kubernetes,
  • it works in hardened environments (non-root, read-only root filesystem, no exec into the container).

Ideas to evaluate

  1. Mount a bundle instead of installing into the image. Deliver the Nextcloud CA bundle as a read-only file: a ConfigMap or Secret created by HaRP on Kubernetes, a bind mount or docker cp of a single file on Docker. No exec, no package tooling, works with a read-only root filesystem. On Kubernetes this needs configmaps (or secrets) permissions for the HaRP service account.
  2. A documented contract for where the bundle is. Set the conventional environment variables on every ExApp (SSL_CERT_FILE, REQUESTS_CA_BUNDLE, CURL_CA_BUNDLE, NODE_EXTRA_CA_CERTS) and possibly an AppAPI specific one, so SDKs can pick it up explicitly. nc_py_api already has NPA_NC_CERT for this, other languages would get the same rule in the ExApp development docs.
  3. Refresh without redeploy. Re-deliver the bundle when it changes (certificate imported or removed, server update brings a newer bundle), for example on ExApp enable, through a background job, or with an occ command. With a mounted ConfigMap the update can propagate without touching the pod.
  4. Let the admin reference an existing trust source. A daemon option that points to a ConfigMap or Secret already managed in the cluster (e.g. by trust-manager), for environments that manage trust centrally.
  5. Keep images fresh anyway. Scheduled rebuilds of test-deploy (and a recommendation for ExApp authors) so base image updates are picked up. This only mitigates the public root case and does nothing for private CAs, so it complements the points above rather than replaces them.
  6. Better diagnostics. When init fails because of TLS verification, surface that reason in the Test Deploy dialog and in the ExApp status instead of a generic init timeout, and make the Test Deploy log message point to certificates rather than suggesting plain HTTP.

Open questions

  • Should the delivered bundle replace the image's CA store or be added to it?
  • One mechanism for all backends (file mount plus environment variables), or keep the in-container installation on Docker and add the mount only for Kubernetes?
  • How do ExApps whose HTTP client ignores both the OS store and the environment variables opt in?
  • Where does the work split between app_api and HaRP, and does it need a new HaRP API version?
Vorherrschende Sprache
PHP
Sterne
199
Forks
26
Ø Merge
2 T. 6 Std.
Gemergte PRs (30 T.)
48

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus nextcloud/app_api

Alle Issues in nextcloud/app_api

Ähnliche Issues

Weitere Issues zu PHP

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.