KNIME Documentation

How secrets work ​

The problem secrets solve ​

When a workflow connects to an external system — a database, cloud storage, an API — it needs credentials. The obvious place to put them is inside the node configuration. But that creates three problems:

  • The credentials are saved with the workflow and travel with it wherever it goes.
  • Anyone with access to the space can read them.
  • When a password changes, every workflow that hard-codes it must be updated individually.

Secrets solve this by storing credentials centrally and fetching them at runtime. The workflow contains no passwords — only a reference to a named secret. The actual value is retrieved when the workflow executes.

Secrets and application passwords both hold credentials, but they work in opposite directions. A secret lets Knime reach another system. An application password lets another tool reach Knime.

How secrets are retrieved ​

Workflows access secrets through the Secrets Retriever node. When the workflow runs, the node retrieves the secrets the executing user has access to, and outputs them through typed ports, such as a credentials flow variable, an OAuth token, a file path. Downstream nodes receive the credential without the workflow ever containing it. If the executing user doesn't have access to a selected secret, the node fails with a "Secret does not exist" error.

Since the secret is fetched at runtime, it is never stored in the workflow. Re-executing the workflow always gets the current value from the secret store, and rotating a credential in one place updates every workflow that references it. Secrets are referenced by internal identifier rather than by name, so renaming a secret doesn't break the connection.

The scoping model ​

Secrets exist at three scopes, which control who can create them and who can use them:

Personal secrets are owned by an individual user and can only be used by that user. They are suited to personal logins: your own Google account, your own API key. Personal secrets cannot be shared.

Team secrets are owned by a team and managed by team admins. Any team member with Use access can retrieve them in a workflow. They are suited to shared service accounts: a read-only database user, or a shared API key for a team integration.

Global secrets are managed by global admins and can be granted to specific users or teams. They are suited to organisation-wide credentials that should not be owned by any individual team.

Within a team or global secret, access is further split into two levels:

  • Use — retrieve the secret in a workflow, but not edit or delete it.
  • Edit — do everything Use allows, plus modify or delete the secret.

Personal secrets don't have separate access levels, since only the owner can use them, and they can't be shared.

Choosing personal vs. team secrets ​

Use a personal secret when the credential is tied to your identity and should not run as you when someone else executes the workflow.

Use a team secret when you are deploying a workflow that runs on behalf of the team, for example, a scheduled job that queries a database using a shared service account. When using the team execution scope the workflow runs as the team, has access to team secrets, and does not require each user to have their own copy of the credential. See Secrets in deployments.

Secret types ​

Knime supports several types to match the authentication methods used by common services:

  • Credentials — username/password or password-only, for databases, REST APIs, and anything that accepts a credentials flow variable.
  • File — a certificate or key file up to 10 KB
  • Generic OAuth2 — for any OAuth2-compliant service without a dedicated type.
  • Google, Microsoft, Databricks, Box — purpose-built types for those platforms with authentication flows matched to each service's requirements

The secret type determines what output port the Secrets Retriever node adds and which downstream nodes can consume it. For service-specific secrets, the Secrets Retriever node replaces the service's authentication node. See the secret types reference for the full list.