K8SJKS/K8SPKCS12 store type definitions should set PasswordOptions.StoreRequired: true

[spbsoluble]

Summary

When a K8SJKS or K8SPKCS12 cert store has its top-level Store Password bound to a PAM provider (e.g. Hashicorp Vault / OpenBao), the UO 26.2.1 fails to retrieve the job configuration with:

Error retrieving job configuration for job id <id>: Value cannot be null. (Parameter 'value')
An exception was encountered processing the job with Id '<id>': Value cannot be null. (Parameter 'value')

The error occurs in OrchestratorJobExecutor before the K8S extension's ProcessJob is called — meaning the framework-level credential resolution is failing, not the extension itself.

Environment

• Command 26.2.1.1350
• Universal Orchestrator 26.2.1 (kyfuseng-development image)
• k8s-orchestrator extension (local net10.0 build, current main branch)
• PAM provider: Hashicorp-Vault (OpenBao) remote PAM, confirmed accessible by PAM token

Store Configuration

store_type: K8SJKS
properties:
  KubeNamespace: keyfactor-lab
  KubeSecretName: lab-jks-store
  CertificateDataFieldName: keystore.jks
  PasswordFieldName: password
  PasswordIsK8SSecret: "false"
pam_credentials:
  - field: Password          # top-level Store Password
    provider: OpenBao-PAM
    parameters:
      Secret: "kfclab-pam/store-passwords"
      Key: "jks-password"

The PAM provider resolves the secret correctly (confirmed via direct vault read). The top-level Password field on the store in Command shows IsManaged: true with correct ProviderTypeParameterValues. The PAM token has read access to the secret path.

Workaround

Remove the PAM binding for field: Password. The extension then creates the keystore with an empty password and writes no password field to the K8S secret. Inventory works with empty password (no password field present → extension uses empty string). This is acceptable for a lab but not production where the keystore password should be managed.

Expected Behaviour

K8SJKS and K8SPKCS12 extensions should support PAM-resolved Store Password, consistent with how ServerPassword PAM resolution works on the same stores and how other store types (e.g. HCVKVJKS) handle PAM-bound secrets.

Investigation Starting Point

The null occurs in OrchestratorJobExecutor during job config retrieval, before the K8S extension is invoked. Check whether the UO framework's PAM credential resolution path for the top-level Password field returns null for remote PAM providers when the store uses in-cluster K8S auth (no ServerPassword value).

[spbsoluble]

Update — root cause identified, not an extension issue

After further investigation the null exception is not caused by PAM credential resolution failing. The root cause is upstream of the extension entirely.

Actual root cause

kfclab was registering K8SJKS and K8SPKCS12 store types without a PasswordOptions payload, causing Command to default both to StoreRequired: false. With StoreRequired: false:

• Command does not enforce a non-null Password on cert store records
• Command returns null Password in the POST /KeyfactorAgents/AnyManagement/Configure response — even when a store_password / PAM binding is present on the store record

The UO 26.x framework's ResolvePamSecret then calls JsonConvert.DeserializeObject<T>(null) on the null Password field without a null guard → ArgumentNullException. The PAM provider is never invoked; the crash happens before it.

Fix

Set PasswordOptions.StoreRequired: true (and Style: "Default") on the K8SJKS and K8SPKCS12 store type definitions. With StoreRequired: true, Command enforces a non-null password on the store record and returns it consistently in all Configure responses (Management and Inventory).

After re-registering the store types with StoreRequired: true and setting an explicit store_password: "changeit" on the cert store records, both Management and Inventory jobs succeed.

Secondary symptom (also resolved)

With StoreRequired: false, Management-Create was building keystores with an empty password (StorePassword ?? "" = "" in ResolvePassword() when Configure returns null). Inventory jobs subsequently tried to open the keystore with the cert store's store_password value → keystore password mismatch on every Inventory run. This is also resolved by StoreRequired: true.

Status

This issue can be closed — no change needed in the k8s-orchestrator extension. The fix is in the store type registration configuration. The PasswordFieldName and PasswordIsK8SSecret store properties referenced in the original store config above are also irrelevant without StorePasswordPath set; ResolvePassword() ignores them in that case.