Model Artifact Integrity with Signature and Verification

Before you sign and verify a model artifact, plan your work using the following considerations.

• Create or identify the model whose artifact you want to sign.
• Use a Vault key suitable for RSA-PSS signing. Specify the key OCID. To use a version of the key other than the latest, specify the OCID of the key version.
  • When your release process requires reproducible signing-key selection, select a specific key version. Otherwise, the current key version is used at signing time.
• Ensure the caller can manage the model and its artifact signature subresource. Signature access follows the owning model resource permissions.
• For model deployment verification, grant the Data Science model deployment resource principal access to use the Vault key that signed the artifact. See IAM Policies for Vault Keys.
  Note
  
  Key rotation: A signature records both the Vault key and key version used to create it. Rotating the key doesn't invalidate existing signatures or model deployments. Verification uses the key and key-version metadata recorded with the signature.
• Plan for asynchronous signing. Digest generation time varies with the model artifact's file count and directory structure.
• Sign only after the model artifact is finalized. Any artifact change requires a new signature.
• Store the artifact signature OCID with the release record so the deployment workflow can reference and verify the intended signature.
• Use tags and display names to make release signatures identifiable during incident response and audits.
• Before deployment, verify that the artifact signature is in the AVAILABLE state. (A successful create request, or CREATING state, isn't proof that the signature is usable.)

For tasks you can perform with artifact signatures, see Managing Artifact Signatures.

Both the human or workload that creates the signature and the model deployment that verifies it need permission to use the signing key. Place policies in the compartment that contains the Vault key, and scope them further to a specific key when your security model requires it. Following are example policies.

• Signature creator principal, with minimum intent to manage the model and use the signing key.

  Allow group <model-signers> to use keys in compartment <vault-compartment>

• Model deployment resource principal, with minimum intent to use the signing key when Data Science verifies the signature during model deployment create, update, patch, and autoscale flows.

  Allow  any-user to use keys in compartment <vault-compartment> where all {request.principal.type 'datasciencemodeldeployment'}

The signature creator must also have permission to manage the model and its artifact-signature subresource. To start, grant the relevant group access to the Data Science model resources in the model compartment, then narrow it according to your tenancy's IAM model.

To restrict a policy to one key, add a target.key.id condition with the key OCID. Validate the final policy syntax in the IAM policy builder and test it with the same principal and key to be used by the signing or deployment workflow. For more information about the policy builder, see Writing Policy Statements with the Policy Builder.

• SHA_224_RSA_PKCS_PSS
• SHA_256_RSA_PKCS_PSS
• SHA_384_RSA_PKCS_PSS
• SHA_512_RSA_PKCS_PSS

A model artifact can have up to five signatures (limit name artifact-signature-count, see Data Science Limits). Signature API requests are also subject to normal control-plane rate limiting.

For troubleshooting, see Artifact Signatures.