We’re having issues deploying our automated supplier onboarding workflow to production. The deployment pipeline runs fine in dev and staging, but fails in prod with SFTP connection errors.
The error occurs when trying to establish connection to external supplier portal:
SFTPConnectionException: Authentication failed
at SupplierOnboardingService.connectSFTP(line 89)
Caused by: Missing credentials for host sftp.supplier-portal.com
Our CI/CD pipeline uses Jenkins and we’ve configured environment variables for SFTP credentials in dev/staging. The secrets manager integration works there, but production deployment can’t access the credentials. Pipeline permissions look identical across environments.
Has anyone dealt with secrets manager integration issues in Vault QMS deployments? Specifically around environment variable mapping for external integrations? We need to understand if this is a pipeline permissions issue or secrets manager configuration problem.
You need to update your deployment automation to inject the credentials at runtime. The connection definition in Vault is separate from the actual credential values. Here’s what we do: pre-deployment script retrieves secrets from AWS Secrets Manager, then uses Vault API to update the connection object with current credentials before the main deployment runs. The connection must be in ‘active’ state with valid credentials before any dependent objects deploy. Check if your pipeline has this pre-deployment credential injection step.
Thanks for the suggestions. Checked IAM roles and the Jenkins service account does have SecretsManagerReadWrite in prod. The secret path is correct - using /prod/veeva/sftp-suppliers. I can manually retrieve the secret using AWS CLI with the same service account credentials.
The deployment manifest does reference the external connection, but I’m wondering if there’s a step missing in how Vault picks up the credentials during deployment. Are there specific Vault API calls or configuration files that need to explicitly map secrets manager values to connection parameters?
From a compliance perspective, make sure your secrets rotation policy isn’t causing this. If prod has stricter rotation windows, the credentials might have rotated between when the pipeline started and when it tried to use them. We enforce 24-hour rotation in prod vs 7-day in lower environments.