• What is the nature and description of the request?

Requesting a new credential type in Ansible Automation Platform (AAP) to support Kerberos PKINIT using X.509 credentials, including cases where the private key is stored on an HSM (via PKCS#11 or similar).

The goal is for AAP jobs to obtain Kerberos tickets with X509_user_identity (PKINIT) instead of keytabs or passwords, while keeping private keys non-exportable and hardware-protected.

• Why does the customer need this? (List the business requirements here)

In customer environment they are moving toward:
• PIV/PKI-enforced Kerberos (PKINIT) for users, and
• Strong requirements that long-term private keys are hardware-protected (HSM-backed, non-exportable).

Today, AAP supports:
• SSH key / password machine credentials, and
• Kerberos via traditional keytabs/passwords handled inside the execution environment (EE).

However, AAP does not provide a first-class way to:
1. Represent a PKINIT-capable X.509 identity as a credential; and
2. Use that identity in the EE via kinit -X X509_user_identity=…, especially where:
• The private key never leaves an HSM, or
• The identity is expressed as a PKCS#11 URI.

This makes it difficult to align AAP with customers PKINIT / PIV enforcement policies without introducing exceptions (e.g., password or keytab-based service principals).

Customer is trying to enable AAP to perform the equivalent of the following Kerberos PKINIT command, with support for HSM-backed keys:

kinit -X X509_user_identity='PKCS11:opensc-pkcs11.so' ad_user@AD.DOMAIN.COM

In other words, customer need an AAP credential type that can drive X509_user_identity using a PKCS#11/HSM-based private key.

• Additional Information:

While the immediate request is Kerberos PKCS#11/HSM support, it would be ideal if this credential type were flexible enough to also be used for OpenSSH public key authentication (using the same HSM-backed key that’s associated with the X.509 certificate).
That would let us standardize on a single HSM-resident key for both Kerberos and SSH scenarios.