Secure credential storage for jobs

[Aashoo Dabral]

As part of my current work, I happened to run into a scenario where Passwords/API keys for batch: RACF, vault, or encrypted files—pros/cons? Thanks in advance for any pointers.

[Anuj Dhawan]

If I have understood the question correctly, these are not exactly alternatives, as they address different requirements.

For a scheduler-submitted job, the scheduler normally runs under its own RACF ID and is authorized through RACF, commonly using SURROGAT, to submit the job under an application batch ID. This avoids storing a RACF password in the JCL.

If the job needs an API key, database password or another external credential, a vault is generally preferable because it supports runtime retrieval, rotation and auditing. An encrypted dataset or file can be used where vault integration is unavailable, but key management and rotation then become additional concerns.

In short, use RACF for the job identity and authorization, a vault for external secrets, and encrypted files only as a fallback. Credentials should not be stored in JCL, PROCs, source code, SYSIN, logs or spool output.

[hollow_rowan69]

Treating RACF identity and external secrets as separate problems, as Anuj outlined, avoids stuffing passwords into JCL. Scheduler submission under SURROGAT keeps the batch user out of the PROC, while API keys and database passwords belong in a vault with rotation and audit, or in an encrypted file only when vault integration is missing. Whatever store is chosen, credentials should never appear in SYSIN, source, spool or logs, and access should be limited to the job's runtime identity. Documenting which jobs use which secret path also makes rotation day much less risky.