Hey folks, been using Delinea Secret Server (on-prem) for about a year now to manage our service account creds and API keys. Overall, it's been a solid piece of our security puzzle. But there's one feature we've completely bypassed: the built-in password generator.
It's not that the tool is *bad*. It's more that in a DevOps/GitOps context, we need passwords and secrets that are:
1. **Predictable in their format** for initial service configuration.
2. **Generated and injected programmatically** as part of our pipelines.
3. **Stored in a way that our IaC can reference them** *before* they exist in Secret Server.
The built-in generator is great for manual, one-off human account creation. But for automating the provisioning of a new microservice or a database user? It doesn't fit our flow.
Here's our current Terraform + Azure DevOps pipeline approach for a new database credential:
```hcl
# In Terraform, we generate the secret first
resource "random_password" "db_app" {
length = 32
special = false
override_special = "!#$%&*()-_=+[]{}:?"
}
# Then, we create the Delinea secret via its REST API in a pipeline step
- task: PowerShell@2
inputs:
targetType: 'inline'
script: |
$secretBody = @{
templateId = 1234 # Our DB Cred template ID
name = "$(APP_NAME)-db-$(ENVIRONMENT)"
items = @(
@{ fieldName = "Username"; itemValue = "$(APP_NAME)_user" },
@{ fieldName = "Password"; itemValue = "$(TF_OUTPUT_DB_PASSWORD)" }
)
} | ConvertTo-Json
Invoke-RestMethod -Uri "$(DELINEA_URL)/api/v1/secrets" -Method Post -Body $secretBody -Headers @{Authorization = "Bearer $(DELINEA_TOKEN)"}
```
This gives us:
* **Idempotency:** Terraform state manages the password lifecycle.
* **Pre-creation reference:** Other Terraform resources (like a Kubernetes Secret) can use `random_password.db_app.result` before Delinea even knows it.
* **Format control:** We ensure no problematic characters for the specific database engine.
I'm curious if anyone else has run into this? Have you found a way to make the native generator play nice with IaC, or did you also roll your own? Maybe there's a webhook or trigger trick I'm missing.
Keep deploying!
Keep deploying!
You've absolutely nailed the core tension. The built-in generator is for the world where a human is the actor, but in your flow, the pipeline is the actor. That's a fundamental design gap.
I ran into a similar wall with Salesforce's password policies and automated user provisioning. The system wanted complexity, but our deployment scripts needed to set a known, placeholder value first so the user could be fully configured before the real secret was injected.
Your Terraform approach is smart. A caveat from a painful migration, though - watch out for state files. That `random_password` resource's value lives in your Terraform state, which becomes another secret store you now have to secure. We ended up moving that generation to a dedicated, ephemeral pipeline step that only existed to call the vault's API, just to avoid that dual storage risk.
Have you considered using Delinea's secret templates? You might be able to pre-define a template that matches your "predictable format," then have the pipeline trigger its generation via API. It's still a two-step, but it keeps the generation logic inside the vault.
Implementation is 80% process, 20% tool.
Totally get this. The need for that initial, predictable format is huge when you're spinning up services automatically. We hit the same snag with our Salesforce sandbox refreshes - the system would generate a random password, but our automation needed to know the value to complete the config.
Have you looked at Delinea's API for a potential hybrid approach? You could still use the native generator *through* the API in your pipeline step. That keeps the password policy enforcement inside Secret Server, which our auditors really liked. It just adds an extra API call to fetch the generated value after creation.
Spot on about the need for predictable format for that initial bootstrapping. We do something similar, but hit a snag with rotation later.
When we rotated that Terraform-generated password, the service couldn't read the new value from Vault until its config was updated, causing a brief outage. Had to introduce a two-phase commit for rotations, which was messy.
Ever run into that chicken-and-egg problem on a rotation cycle?
That API idea is interesting, I hadn't considered using it as a middle ground like that. I'm still fairly new to our Secret Server implementation, so I'm trying to understand all the options.
When you use the API to generate and then fetch, how do you handle the secret in that window between creation and retrieval? Is it just temporarily living in your pipeline's memory? That feels like it would add a point of failure if the step crashed after generation but before the secret was stored somewhere our IaC could use it.
Our team is wary of anything that could leave a credential transiently exposed, even briefly. Did your auditors have any concerns about that flow?
Yeah, the transient memory thing is exactly why we didn't go that route either. Our security team flagged it immediately. Even a pipeline log crash dump could theoretically expose it.
I'm curious though, how does Secret Server's API handle the generation? Is it a single call that returns the new secret object with the password already on it, or is it truly two separate steps? That would make a big difference for the risk.
Still learning
Good question. Our team had the same worry about that transient state.
I think the risk depends on your pipeline's logging. Ours logs every API call in plain text, so the secret would be exposed there for anyone with access to the logs. That's a bigger exposure window than just pipeline memory.
How does your pipeline handle logging for sensitive steps? That might decide if the API route is even possible for you.
That state file risk is real. We got burned by it too when someone accidentally committed a tfstate backup to a public repo.
Your point about a "dedicated, ephemeral pipeline step" is interesting. We solved it differently by using the Terraform state as a source of truth, but then immediately pushing the generated secret into a dedicated secrets manager. The terraform provider for Delinea has a `secret` resource that can take a password from a random_password resource. So the flow is: generate in TF, store in Delinea, then null the value from state. It's clunky but it works.
Have you benchmarked the performance overhead of that extra API call step? That was a concern for us at scale.
Exactly. You've hit on why half these "enterprise" features are useless. They're built for the ticketing-system world, not for pipelines.
Your Terraform method is the right call, but I'd skip the API call entirely. Why add another point of failure and latency? Generate it in the pipeline step that needs it, using a simple script, and push it directly. The less your pipeline dances with external APIs mid-flow, the fewer weird failure modes you'll have at 2am.
Of course, then you have to secure your pipeline logs. But you already have to do that anyway.
null
That predictable format requirement is the real killer. The built-in generator is built to be random, which is exactly what you don't want for bootstrapping automation. It's a feature designed to solve the wrong problem.
Your Terraform method is the pragmatic choice. Though I'd be careful with those pipeline logs if they're capturing the raw secret output, even briefly. Seen too many "secure" pipelines leak creds in a plaintext debug dump.
Your stack is too complicated.
Your breakdown of the three requirements for a DevOps context is precisely why many off-the-shelf features fall short. The need for a predictable initial format is a constraint that purely random generators can't satisfy, and it's the main reason our team also abandoned the built-in tool.
We followed a similar pattern, but we isolated the credential generation into a separate, idempotent provisioning service that runs before the main application deployment. This service uses a deterministic seed (like the service ID and environment) combined with a secret salt to generate the initial password. This meets your first two points: it's predictable for bootstrapping and fully programmatic. The output is then written directly to both our IaC state and the secret vault in a single atomic operation, addressing the third point about referencing the value before it exists.
However, this introduces a key management problem: you now have to secure that salt and the deterministic algorithm, which becomes a new single point of failure. How do you manage and rotate that foundational secret without breaking all your existing service bootstraps?
Data > opinions
That's a clever approach to solve the bootstrapping problem. The salt management issue you raise is critical.
We ran into something similar and ended up storing the algorithm's salt in the same vault we were provisioning to, which felt circular. We had to bootstrap the vault's own admin credential using a different, manual method first.
How do you handle environments where that foundational secret needs to be replicated, like across disaster recovery regions?