Skip to main content
Version: 1.2

Upgrade from 1.1 to 1.2

Hub 1.2 moves authentication into a new hub-auth component and changes some chart values. Make these changes to your values file before you run helm upgrade to 1.2.0.

  1. Enable and configure hub-auth. hub-auth now serves OIDC login, token exchange, the signing keys hub-core verifies tokens against, and the identityproviders, users, and groups APIs. The Gateway routes those paths to hub-auth, but the chart doesn't deploy it unless you enable it. Without it, nobody can log in. Add the hub-auth block from step 5 of the install guide: set enabled: true, auth.issuerURL and auth.externalURL to Hub's external URL, auth.frontendURL to the UI URL, and a postgresql block that points at the same database as hub-core. If your 1.1 values set hub-core.api.externalURL, move that URL to global.hubCoreExternalUrl, which hub-core, the Console, and in-cluster connectors all read, and reuse it for the hub-auth URLs. In IAM mode, give the hub-auth ServiceAccount the same database role. The OIDC redirect URI you registered with your provider (https://api.<your-domain>/oidc/callback) doesn't change.

  2. Move a pinned signing key. hub-auth now holds the key for hub-issued tokens, and the chart no longer uses hub-core.api.signingKey. hub-auth generates a new key unless you set hub-auth.auth.signingKey.existingSecretRef. If you pinned hub-core.api.signingKey.existingSecretRef, set the same Secret under hub-auth.auth.signingKey.existingSecretRef.

    hub-auth also signs browser sessions now, with its own hub-auth.auth.hmacKey. If you pinned hub-core.api.hmacKey.existingSecretRef, and existingPreviousSecretRef if you use it, set the same Secrets under hub-auth.auth.hmacKey. Otherwise hub-auth generates a new key, and everyone has to sign in to the Console again after the upgrade. To keep sessions on an install that didn't pin the key, set hub-auth.auth.hmacKey.existingSecretRef.name to the hub-core-hmac Secret that 1.1 generated.

  3. Remove values the 1.2 charts reject. The charts validate values against a strict schema, so a removed key fails the upgrade:

    • hub-connector: remove connector.hub.allowInsecure. The connector now uses plain HTTP only for in-cluster addresses (localhost, *.svc, and *.svc.cluster.local) and requires HTTPS for every other Hub URL, with no override. Point connector.hub.url at the Hub's HTTPS address, or at its in-cluster Service when the connector runs in the Hub's cluster.
    • hub-core: replace otelGateway.metricAllowlist with otelGateway.extraMetricAllowlist. The new list adds patterns to the chart's built-in allowlist rather than replacing it, so list only the extra metrics you need.

  4. Re-mint unused registration tokens. A 1.2 migration drops the stored registration tokens, and the new authenticator refuses any token minted before the upgrade. For any connector that hasn't registered yet, mint a new token after the upgrade.

  5. Point 1.1 connectors at hub-auth. Connectors on 1.1 keep working against a 1.2 Hub, so you can upgrade them after the Hub. Before you upgrade the Hub, set connector.hub.tokenExchangeUrl on each 1.1 connector that reaches hub-core directly to the hub-auth Service on port 8444 (for example http://hub-auth.hub.svc.cluster.local:8444). Connectors that use the Hub's gateway URL need no change.

    A 1.1 connector that restarts within 24 hours of the registration token in its credentials Secret being minted fails to start, because the 1.2 Hub rejects the repeat registration. Remove the token from the Secret, or upgrade that connector to 1.2.

  6. Expect a new Deployment. The discovery aggregator is on by default and runs as hub-core-aggregator. It serves /apis and /openapi on the API hostname.

Users may need to log in again after the upgrade.

The upgrade applies migrations that drop tables and columns. Rolling back to 1.1 requires restoring the database backup you took before the upgrade.

Follow the general upgrade procedure to run the upgrade itself.