Deployment failures when using Secrets in structured URI fields (e.g., imageRef)

Products

• VCF Operations/Automation (formerly VMware Aria Suite)

Issue/Introduction

In VMware Aria Automation 8.x, using secrets (e.g., ${secret.mySecret}) inside structured URI fields such as imageRef causes provisioning to fail.

The deployment fails with a URI parsing error, and logs show the unresolved secret placeholder is interpreted as part of the final URL, rendering it invalid.

Example usage that leads to failure:

imageRef: "https://${username}:${secret.artpwdv3}@RepoFQDN/repository/template.ova"

Error:

Could not access the file at [https://username:((secret:v1:...))@RepoFQDN/...] org.apache.http.client.ClientProtocolException: URI does not specif

Environment

VMware Aria Automation 8.x

Cause

Secrets are resolved after provisioning templates are parsed. When a secret placeholder (e.g., ((secret:v1:...))) appears in a structured field like a URI, the provisioning service attempts to parse it prematurely. This causes a malformed URI error before the secret is substituted or decrypted.

Resolution

Resolution

Avoid using secrets directly within structured URI fields.

Recommended alternatives:

• Inject secrets into scripts or cloudConfig fields where credentials can be used outside of URI parsing logic.

• Split URL construction into separate properties or environment variables if credentials must be dynamic.

• Use service accounts or predefined variables for cases where secrets cannot be passed securely via supported fields.

Additional Information

This behavior is not a regression; it is a limitation in current URI parsing behavior within provisioning-service-app. The system cannot parse unresolved secret tokens embedded in structured fields.