Configuration
Everything under the harbor: key in values.yaml is passed straight to the upstream Harbor
chart. The pack adds nebariapp.* and oidcSetup.*.
Storage
Section titled “Storage”By default the pack is self-contained: Harbor’s bundled Postgres and Redis run on PVCs and the registry stores blobs on a filesystem PVC. This is ideal for a quick start but not for production scale.
Object storage for the registry
Section titled “Object storage for the registry”harbor: persistence: imageChartStorage: type: s3 s3: region: us-east-1 bucket: harbor-registry regionendpoint: https://s3.us-east-1.amazonaws.com # or a MinIO endpoint accesskey: <access-key> secretkey: <secret-key> secure: trueExternal managed Postgres and Redis
Section titled “External managed Postgres and Redis”harbor: database: type: external external: host: postgres.example.com port: "5432" username: harbor password: <password> coreDatabase: registry sslmode: require redis: type: external external: addr: redis.example.com:6379 password: <password>PVC sizes (bundled mode)
Section titled “PVC sizes (bundled mode)”harbor: persistence: persistentVolumeClaim: registry: { size: 50Gi } database: { size: 5Gi } redis: { size: 5Gi } trivy: { size: 5Gi } jobservice: { jobLog: { size: 5Gi } }Pack-specific values
Section titled “Pack-specific values”| Key | Default | Description |
|---|---|---|
nebariapp.enabled | false | Emit the NebariApp CR (set true on Nebari). |
nebariapp.hostname | — | Required when enabled; Harbor’s external hostname. |
nebariapp.manageNamespace | false | Emit a nebari.dev/managed Namespace, or label it yourself. |
nebariapp.auth.enabled | true | Provision the Keycloak OIDC client. |
nebariapp.auth.enforceAtGateway | false | Keep false — Harbor does OIDC itself. |
nebariapp.auth.redirectURI | /c/oidc/callback | Harbor’s OIDC callback path. |
nebariapp.auth.scopes | [openid, profile, email, offline_access, groups] | Requested OIDC scopes. |
nebariapp.landingPage.* | Harbor card | Landing-page card metadata. |
oidcSetup.enabled | true | Run the Job that switches Harbor to oidc_auth. |
oidcSetup.adminGroup | "" | Keycloak group mapped to Harbor system-admin. |
oidcSetup.autoOnboard | true | Auto-create Harbor users on first OIDC login. |
oidcSetup.image | curlimages/curl:8.11.0 | Image used by the config Job. |
oidcSetup.projectCreationRestriction | adminonly | Who may create projects: adminonly, everyone, or "" to leave Harbor’s setting alone. |
oidcSetup.systemConfig | {} | Extra Harbor system settings (config-API keys) merged into the same configuration call. |
harbor.externalURL | — | Set to https://<hostname>. |
harbor.harborAdminPassword | — | Admin password; supply at install time. |
Harbor system settings
Section titled “Harbor system settings”Harbor keeps settings such as project_creation_restriction in its database, not in Helm
values, so the OIDC config Job writes them with the same PUT /api/v2.0/configurations call
it uses for auth. Two values feed that payload:
oidcSetup: # adminonly | everyone | "" (leave Harbor's current setting alone) projectCreationRestriction: adminonly systemConfig: robot_name_prefix: "robot$" robot_token_duration: 30 # days audit_log_forward_endpoint: "syslog://logger:5140"systemConfig keys are Harbor config-API names and values keep their YAML type (numbers and
booleans are sent unquoted, strings quoted), so new settings need no chart change. Settings
with security implications keep an explicit value of their own: auth_mode, the oidc_*
settings, and project_creation_restriction are rejected in systemConfig (the render fails
naming the key) so they cannot silently override the chart-managed values.
With oidcSetup.autoOnboard enabled, everyone who can log in through Keycloak gets a Harbor
account, so the pack defaults projectCreationRestriction to adminonly. Harbor’s own
default is everyone, so upgrading an existing SSO install changes behaviour: onboarded
users who could previously create projects no longer can. Set it to everyone to keep the
old behaviour, or to "" to stop managing the setting entirely. Standalone installs
(oidcSetup.enabled=false) never run the Job and are unaffected.
See the NebariApp CRD reference for the full set of NebariApp fields.