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 fieldsOCM ships with the following built-in credential types:
| Credential Type | Used With | Purpose |
|---|---|---|
OCICredentials/v1 | OCIRegistry consumers | OCI registry username/password and token auth |
HelmHTTPCredentials/v1 | HelmChartRepository consumers (HTTP/S) | Helm HTTP repository auth and TLS client certs |
RSACredentials/v1 | RSA/v1alpha1 consumers | RSA signing and verification key material |
GPGCredentials/v1alpha1 | GPG/v1alpha1 consumers | GPG signing and verification key material |
OIDCIdentityToken/v1alpha1 | SigstoreSigner/v1alpha1 consumers | OIDC token for Sigstore keyless signing via Fulcio |
TrustedRoot/v1alpha1 | SigstoreVerifier/v1alpha1 consumers | Sigstore trust material for private infrastructure verification |
DirectCredentials/v1 | Any consumer | Legacy 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 credentialsInspect the fields of a specific credential type:
ocm describe types credentials OCICredentials/v1Export the raw JSON Schema for a type (useful for tooling and validation):
ocm describe types credentials OCICredentials/v1 -o jsonschemaOCICredentials/v1
Example
consumers:
- identity:
type: OCIRegistry
hostname: registry.example.com
credentials:
- type: OCICredentials/v1
username: my-user
password: my-passwordToken-based authentication:
consumers:
- identity:
type: OCIRegistry
hostname: registry.example.com
credentials:
- type: OCICredentials/v1
refreshToken: my-oauth2-refresh-tokenUsed 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-passwordMutual TLS:
consumers:
- identity:
type: HelmChartRepository
hostname: charts.internal
scheme: https
credentials:
- type: HelmHTTPCredentials/v1
certFile: /path/to/client.crt
keyFile: /path/to/client.keyUsed 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.pemInline 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-passphraseUsed 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-tokenUsed 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.jsonUsed 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-passwordRSA 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.pemDirectCredentials/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.
Related Documentation
- Reference: Credential Consumer Identities — identity types and their attributes
- Concept: Credential System — how credential resolution works end-to-end
- Tutorial: Understand Credential Resolution — step-by-step matching examples