Credential Types

This page is the technical reference for OCM’s built-in credential types — the values you place in the credentials: field of a consumer entry. For a high-level introduction, see Credential System.

Overview

Every consumer entry in .ocmconfig has a credentials: list. Each entry in that list has a type that determines which fields are expected:

consumers:
  - identity:
      type: OCIRegistry
      hostname: registry.example.com
    credentials:
      - type: <credential-type>
        # ... type-specific fields

OCM ships with the following built-in credential types:

Credential TypeUsed WithPurpose
OCICredentials/v1OCIRegistry consumersOCI registry username/password and token auth
HelmHTTPCredentials/v1HelmChartRepository consumers (HTTP/S)Helm HTTP repository auth and TLS client certs
RSACredentials/v1RSA/v1alpha1 consumersRSA signing and verification key material
GPGCredentials/v1alpha1GPG/v1alpha1 consumersGPG signing and verification key material
OIDCIdentityToken/v1alpha1SigstoreSigner/v1alpha1 consumersOIDC token for Sigstore keyless signing via Fulcio
TrustedRoot/v1alpha1SigstoreVerifier/v1alpha1 consumersSigstore trust material for private infrastructure verification
DirectCredentials/v1Any consumerLegacy untyped key-value fallback (also Credentials/v1)

All typed credential types use flat top-level fields. DirectCredentials/v1 uses a nested properties: map — it is the universal fallback and all existing .ocmconfig files using Credentials/v1 continue to work unchanged.


Discovering Credential Types

The ocm describe types command exposes the full set of credential types registered in your OCM installation, including any types introduced by installed plugins.

List all available credential types:

ocm describe types credentials

Inspect the fields of a specific credential type:

ocm describe types credentials OCICredentials/v1

Export the raw JSON Schema for a type (useful for tooling and validation):

ocm describe types credentials OCICredentials/v1 -o jsonschema

OCICredentials/v1

Example

consumers:
  - identity:
      type: OCIRegistry
      hostname: registry.example.com
    credentials:
      - type: OCICredentials/v1
        username: my-user
        password: my-password

Token-based authentication:

consumers:
  - identity:
      type: OCIRegistry
      hostname: registry.example.com
    credentials:
      - type: OCICredentials/v1
        refreshToken: my-oauth2-refresh-token

Used With

OCIRegistry consumer identities. For OCI-backed Helm repositories, also use OCICredentials/v1 (not HelmHTTPCredentials/v1).


HelmHTTPCredentials/v1

Example

Username/password:

consumers:
  - identity:
      type: HelmChartRepository
      hostname: charts.example.com
      scheme: https
    credentials:
      - type: HelmHTTPCredentials/v1
        username: helm-user
        password: helm-password

Mutual TLS:

consumers:
  - identity:
      type: HelmChartRepository
      hostname: charts.internal
      scheme: https
    credentials:
      - type: HelmHTTPCredentials/v1
        certFile: /path/to/client.crt
        keyFile: /path/to/client.key

Used With

HelmChartRepository consumer identities that use HTTP/S transport. For OCI-based Helm repositories, use OCICredentials/v1 instead.


RSACredentials/v1

Example

File-based (recommended):

consumers:
  - identity:
      type: RSA/v1alpha1
      algorithm: RSASSA-PSS
      signature: default
    credentials:
      - type: RSACredentials/v1
        privateKeyPEMFile: /path/to/private-key.pem
        publicKeyPEMFile: /path/to/public-key.pem

Inline keys:

consumers:
  - identity:
      type: RSA/v1alpha1
      algorithm: RSASSA-PSS
      signature: default
    credentials:
      - type: RSACredentials/v1
        privateKeyPEM: |
          -----BEGIN RSA PRIVATE KEY-----
          MIIEpAIBAAKCAQEA...
          -----END RSA PRIVATE KEY-----
        publicKeyPEM: |
          -----BEGIN PUBLIC KEY-----
          MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...
          -----END PUBLIC KEY-----

Used With

RSA/v1alpha1 consumer identities.


GPGCredentials/v1alpha1

Example

consumers:
  - identity:
      type: GPG/v1alpha1
      algorithm: application/vnd.ocm.signature.gpg
      signature: default
    credentials:
      - type: GPGCredentials/v1alpha1
        privateKeyPGPFile: /path/to/private.asc
        publicKeyPGPFile: /path/to/public.asc
        passphrase: my-passphrase

Used With

GPG/v1alpha1 consumer identities (signing and verification with OpenPGP keys).


OIDCIdentityToken/v1alpha1

Example

consumers:
  - identity:
      type: SigstoreSigner/v1alpha1
      signature: default
    credentials:
      - type: OIDCIdentityToken/v1alpha1
        tokenFile: /path/to/oidc-token

Used With

SigstoreSigner/v1alpha1 consumer identities (Sigstore keyless signing path only; not used during verification).


TrustedRoot/v1alpha1

Example

consumers:
  - identity:
      type: SigstoreVerifier/v1alpha1
      signature: default
    credentials:
      - type: TrustedRoot/v1alpha1
        trustedRootJSONFile: /path/to/trusted-root.json

Used With

SigstoreVerifier/v1alpha1 consumer identities (Sigstore verification path only; not used during signing).


DirectCredentials/v1

Example

OCI registry with Credentials/v1:

consumers:
  - identity:
      type: OCIRegistry
      hostname: registry.example.com
    credentials:
      - type: Credentials/v1
        properties:
          username: my-user
          password: my-password

RSA signing with Credentials/v1:

consumers:
  - identity:
      type: RSA/v1alpha1
      algorithm: RSASSA-PSS
      signature: default
    credentials:
      - type: Credentials/v1
        properties:
          privateKeyPEMFile: /path/to/private-key.pem
          publicKeyPEMFile: /path/to/public-key.pem

DirectCredentials/v1 property keys use the same camelCase names as the corresponding typed credential fields ( e.g., privateKeyPEMFile, not private_key_pem_file). The RSA binding additionally accepts the old snake_case keys ( private_key_pem_file, public_key_pem_file) as a deprecated backward-compatibility fallback — all other bindings require camelCase.

When to use

Use Credentials/v1 / DirectCredentials/v1 when:

  • Migrating from an existing configuration and you want no changes
  • Working with consumer identity types that do not yet have a corresponding typed credential type

Use the typed alternatives (OCICredentials/v1, HelmHTTPCredentials/v1, RSACredentials/v1) for new configurations — they provide field validation at configuration parse time and clearer field names.


Plugin-Declared Types

Plugins can introduce additional credential types beyond the built-ins listed here. A plugin declares its custom types in the customCredentialTypes field of its capability spec. Those types are registered at plugin discovery time and available in .ocmconfig alongside the built-ins.

External plugin credential types use a reverse-domain prefix by convention (e.g., com.hashicorp.vault.VaultCredentials/v1). This prevents name collisions between independently developed plugins.

For details on how plugins declare and register credential types, see Plugin System.