Repository navigation
Filebrowser: Auto Discover S3 Buckets #157
Description
Activity
- added a parent issue
on May 21, 2026 Update: As of 27.05.2026, the Stackable architecture has no clear implementation of how S3 credentials, connections and discoverability should be handled. While the scope of the connection in this S3 file browser frontend is set to just dicover and use any Stackable S3 resources inside of the Kubernetes cluster, many concerns are still present:
- Kubernetes Native: It is undecided on wether to use a native Kubernetes client in the Svelte backend (kubernetes TypeScript package) or a Rust proxy to list the S3 resources running inside of a cluster.
- Authorization: In either case of using native Kubernetes or running a proxy, the software solution still requires a token to act inside of that cluster. It is unclear on how this method of authorization should be handled.
- Scope of Discovery: There are 3 different scopes of S3 resources inside of a stacklet. The order of hierarchy is
Stacklets > Buckets > Connections. Thus it is unclear on which of these should be dicoverable as the scope of authorization increases with the order inside the hierarchy (e.g. dicovery of stacklets require namespace attribution to work with 2x inline definitions of S3 connections). For more information, see the docs.
- removed a parent issue
on May 27, 2026
S3 Buckets (and later on HDFS) and connections that are hosted in the same Kubernetes cluster need to be automatically discovered to be used. This feature needs to be discussed with the rest of the Stackable team to find a working solution for all applications that need a centralized auto discover method of these storage containers. The currently most favorable option is to use Stackable Cockpitd which is a REST service allowing the frontend to query information about the cluster it's running in.
Additionally, all Stacklet resources should have an inspector to display the YAML configuration of a given service inside the frontend (such as an S3 resource).