Let's be honest with each other.  We've all done it.

Whether it was a late-night deployment script, a quick and dirty data load process, or a configuration change, we've all hardcoded a password in plain text.  It feels fast.  It gets the job done.  And in that moment, it feels harmless.

But that convenience is a ticking time bomb.  Storing sensitive credentials—such as SQL logins, service account passwords, and even Windows AD accounts — in plain text is one of the single biggest risks in any IT environment.  If you're leaving these in your PowerShell, YAML, or t-SQL script files, it's like leaving the keys under the doormat or on top of the visor in your car.

In today's world, security cannot be treated as an afterthought.  It needs to be the foundation of everything you build.  

If you're using Ansible to automate your management of SQL Server, learn to utilize Ansible Vault for secrets management.  Never heard of it?  You're in luck.  Stick with me over the next few weeks, and we'll dive into how to use it with a few working examples.

How bad could it really be?

There are numerous case studies in which data leaks were a direct result of secrets being left in plaintext, resulting in huge fines.

As a DBA, you're tasked with keeping your organization's data safe while also delivering results faster than ever (hence your need to learn and automate more tasks). Just imagine those T-SQL, PowerShell, or Ansible playbooks being checked into your company's source control, and they contain the SA password.  It could be a bad day for your career.

Every hardcoded password is a landmine.  A disgruntled employee, a compromised developer account, or even an accidental leak could lead to a catastrophic data breach. 

What can you do differently?

This constant dread of remembering where you've stored, or your team has stored, plain text passwords doesn't have to be your reality.  

When you're asked to deploy a new SQL Server, you could run a single Ansible playbook.  That playbook retrieves the necessary passwords from a secure, encrypted file known as a "vault."  The password is used in memory during the playbook run and is never written to a log file or displayed on the screen (as long as you're not reporting the decrypted value via Ansible's debug command and utilize no_log: true for the task using the secret).  

When a developer needs to connect to a database for a CI/CD pipeline, you provide them access to run a playbook that uses the vault.  They get the access they need without ever seeing the credential itself.

This represents the shift from a reactive DBA to a more proactive architect.  You're no longer just closing tickets and cleaning up messes; you're designing resilient, secure, and auditable systems.  This is how you multiply your impact.  You're not just managing 100 servers anymore; you're managing the systems that manage 100 servers.  That confidence, knowing your automation is secure by design, is how you reclaim your time and advance your career.

Your First Steps with Ansible Vault

Ansible Vault is built directly into Ansible, and it's surprisingly easy to get started.

In this series, I'll walk you through the exact, practical steps you need to take to secure your automation from the start.  We will cover:

• Your First Encrypted File: We'll start by creating your first vault to hold an entire file of sensitive variables.
• Granular Security: Next, I'll demonstrate how to encrypt a single line of text, such as a password, within a larger configuration file.
• Automating the Vault: Finally, we'll make it practical for real-world automation by utilizing password files and environment variables, allowing your automated jobs to run without requiring a password.

So, about those plain-text passwords.  Do you or your team have any that need to be removed?  Do you know for certain?  

See you next week!