feat: Add S3 Data Connections UI and automated PodDefault creation in Central Dashboard

[mishraa-pooja]

Checks

• I have searched the existing issues.
• My request is related to one of the components in the kubeflow/dashboard repository.

Motivation

Currently, configuring S3 data connections in Kubeflow requires users to manually:

1. Create Kubernetes Secrets with the correct keys (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_S3_ENDPOINT, etc.)
2. Manually author PodDefault YAML resources that reference those secrets
3. Manually configure environment variable injection and optional S3 filesystem mounts (s3fs-FUSE or CSI S3)
4. Ensure all labels and annotations are correct so the admission webhook picks them up

This is error-prone, requires kubectl access, and is not accessible to data scientists who primarily work through the Kubeflow UI. Other platforms (e.g., OpenShift AI / RHODS) already provide a first-class "Data Connections" UI that abstracts away this complexity.

We propose adding a Data Connections page to the Central Dashboard that lets users create, list, and delete S3 data connections entirely through the UI — along with a new s3-poddefault-controller that automatically reconciles labeled Secrets into PodDefaults so notebooks can consume S3 credentials without any manual YAML authoring.

Implementation

Components Changed

1. Central Dashboard — New "Data Connections" sidebar page

• A new data-connections-view Polymer component added to the Central Dashboard
• Sidebar entry added under the existing navigation
• Users can:
  • View all S3 data connections in their namespace
  • Create new data connections via a form (name, bucket, access key, secret key, endpoint)
  • Enable optional S3 filesystem mount with configurable mount path
  • Set an optional environment variable prefix for namespacing env vars
  • Delete existing data connections

2. Central Dashboard — Backend S3 Service (s3_service.ts)

• New backend service that manages S3 credentials as Kubernetes Secrets
• Secrets are labeled with kubeflow.org/s3-data-connection: true for controller discovery
• API endpoints:
  • GET /api/s3credentials — list data connections in a namespace
  • POST /api/s3credentials — create a new data connection
  • DELETE /api/s3credentials/:id — delete a data connection
• RBAC updates: ClusterRole and Role updated to allow secrets read/write in user namespaces

3. New component: s3-poddefault-controller

• A Kubernetes controller (Go) that watches for Secrets with the kubeflow.org/s3-data-connection label
• Automatically creates a corresponding PodDefault that injects S3 environment variables into pods
• When mount is enabled, configures either s3fs-FUSE sidecar or CSI S3 volume mount
• Full lifecycle management: PodDefaults are updated when secrets change and garbage-collected when secrets are deleted
• Supports leader election for HA deployments
• Includes unit tests and Kustomize manifests for deployment

Are you willing & able to help?

• I am able to submit a PR!
• I can help test the feature!

[christian-heusel]

Hey @mishraa-pooja thanks a lot for your proposal and being interested to contribute this! 🎉

I briefly read through the current feature request and I have a few questions:

• Do you already have an implementation for this and experience using it? I'm asking because I think you posted some screenshots to Slack if I remember correctly 😄
• Is there a particular reason why you opted for a fuse-mount instead of a model where the tool just populates a PVC with the data?
• Given that there also is a similar feature in the OpenShift AI platform, what inspiration can we draw from the functionality there? Maybe some RH folks can chime in regarding the functionality / design and potentially also point us to some code if its FOSS
• I think quite some of the functionality that we're looking for is already coming with the Notebooks v2 rewrite (i.e. with regard to secrets management); Did you already look at the codebase for it? Potentially it might be a better starting point with regards to the features we're looking to support here: https://github.com/kubeflow/notebooks/tree/notebooks-v2

[mishraa-pooja]

1. Do you already have an implementation?

Yes! I have a working implementation that's been tested. The s3-poddefault-controller (Go, controller-runtime) watches labeled Secrets and auto-reconciles them into PodDefaults. The Central Dashboard has a full Data Connections page with create/list/update/delete, backed by an S3 service that manages credentials as labeled Kubernetes Secrets. Screenshots were shared on Slack earlier (then it supported single mount)

2. Why FUSE mount instead of PVC-populate?

FUSE (s3fs) gives live, bidirectional access — reads and writes are immediately reflected in S3 without needing to pre-download datasets or run sync jobs. For data scientists working with large or frequently-updated datasets in notebooks, this avoids the "stale copy" problem. That said, the controller already supports multiple mount types via a MOUNT_TYPE config (s3fs, csi-s3), so adding a PVC-populate strategy for batch workloads is straightforward.

3. Inspiration from OpenShift AI?

Yes — RHODS (now OpenShift AI) via opendatahub-io/odh-dashboard (Apache 2.0) was a key reference. They've evolved from hardcoded S3 data connections to a generic connectionTypes framework supporting multiple backends. Key takeaways adopted: secret-backed credential storage with typed labels, project/namespace-scoped management, and form-based UX with validation. Their extensibility model (supporting S3, databases, model registries under one abstraction) informs our future direction.

4. Notebooks v2 overlap and gaps?

I've reviewed the notebooks-v2 branch. There's significant overlap:

• Full Secrets CRUD API (GET/POST/PUT/DELETE /api/v1/secrets/{namespace})
• Secret mounting via PodSecretMount in WorkspaceSpec
• React frontend with create/attach/delete modals
• Permission labels (can-mount, can-update) and audit metadata

However, notebooks-v2 currently lacks:

• No S3-specific secret type — all secrets are generic Opaque key-value pairs with no structured validation for AWS credentials
• No automatic PodDefault generation — secrets are only mounted as files via explicit pod template config; there's no admission-webhook-based env var injection
• No S3 filesystem mounting — no FUSE sidecar or CSI S3 integration; only raw file mounts of secret keys
• No "Data Connections" abstraction — no higher-level concept grouping endpoint + bucket + credentials + mount config into a single manageable entity
• No connection testing — no endpoint to validate S3 credentials/bucket accessibility before saving
• No env-var injection with prefix namespacing — no support for injecting <PREFIX>_AWS_ACCESS_KEY_ID etc. to avoid collisions when multiple connections are used

The s3-poddefault-controller and the Data Connections UI fill exactly these gaps. The ideal path forward is integrating the Data Connections UX into notebooks-v2's existing secrets infrastructure while keeping the controller as a standalone component for the PodDefault reconciliation.