Secrets management in Ascender and Ansible
A secret is any private information automation needs, such as the SSH password behind ansible_password or the vCenter password a VMware module requires. This lesson starts with why putting those values in plain text in a playbook is a bad idea: playbooks live in Git, and a repository that is private today can be public tomorrow. Greg Sowell then works up through progressively better options and explains the trade-offs of each.
Ansible Vault can encrypt whole files or single variables with 256-bit encryption, and Ascender supports it through a Vault credential that supplies the password at runtime. Still, vaulted secrets in a repository are a future decryption risk and harder for auditors, so the preferred home is the Ascender credential store, where machine credentials inject usernames, passwords and SSH keys at launch and built-in types cover Amazon, Google and Azure. Custom credential types extend this to anything else, such as an access key for CIQ's Mountain repository, injecting fields as extra vars or environment variables while marking values secret so they are hidden in the interface and job logs.
For teams that do not want secrets stored statically at all, secrets engines such as HashiCorp Vault, CyberArk Conjur and Delinea are queried when a job launches, and per-host password lookups are possible with a role. Everything covered applies equally to Ascender, AWX and AAP.
Key takeaways
- Plain text passwords in playbooks end up in Git history, where an accidentally public repository can expose them.
- Ansible Vault encrypts files or individual variables, and an Ascender Vault credential supplies the password at runtime.
- Vaulted secrets in a repository could become decryptable later and complicate audits, so storing them in files is discouraged.
- Ascender machine credentials inject username, password or SSH key as ansible_user and ansible_password when a job launches.
- Custom credential types store arbitrary secrets like API keys and inject them as extra vars or environment variables, masked in logs.
- Secrets engines such as HashiCorp Vault and CyberArk Conjur are queried at launch so no secret is stored statically in Ascender.
Questions this video answers
How does Ascender handle Ansible Vault encrypted files?
You create a credential of type Vault and enter the vault password. When a job runs, Ascender uses it to decrypt vaulted variables in a playbook or an entire vaulted file, emulating the ask-vault-pass or password file options used on the command line.
What is a custom credential type in Ascender?
It is a credential type you define with your own fields, such as a username and a password or an API token, marking sensitive fields as secret. Ascender stores the values securely and injects them into the playbook at runtime as extra vars or environment variables, and secret values are masked in the interface and in task logging.
What is a secrets engine and which ones does Ascender support?
A secrets engine is a server or cluster that stores secrets and answers queries. When a job uses a credential backed by one, Ascender pauses before executing, retrieves the password, key or token, and uses it for that run. Supported engines include HashiCorp Vault, CyberArk Conjur and Delinea, formerly Thycotic, among others.
This video is part of the Ascender Pro playlist. Browse every CIQ video by product and topic.
Transcript
hey everybody I'm Greg Sowell and I'm here with another ciq demo or maybe tutorial or perhaps lesson lesson feels more fitting but today I'm going to be talking about how you can do Secrets management inside of Ascender and I guess me you know to some extent anable itself kind of how that Secrets management work and so what is a secret it's really just any piece of private information that you want to keep private so here's an example of using some secrets in a Playbook so here in the VAR section you can see I have anible uncore password and now that's a magic variable
and that is what uh password is going to be used when it's going to try and say for example SSH into a remote host right a server or a network a piece of a network equipment right it's going to try and s shn and I'm actually setting my secret here you can see my secret is my secret I also have an example here of a task and so something really common for me is to manage my VMware environment and one of the things it requires for those modules is to you know have a password associated with it right you have to actually plug in the
password uh that it's going to utilize to connect to your V Center and here you can see I've putting it plain text now this technically would work and it is valid but I wouldn't recommend it I generally try not to say best practice but it is a best practice not to put plain text passwords kind of anywhere let alone in your playbooks right so generally what we're going to do is we're going to create playbooks we're going to put those into our get repositories right our SCM or Source Control Management while that lives in there now so if I put a plain text password that's
going to be in that version history you know most of you are going to be putting stuff in private repositories but what happens if you accidentally make that public right you could be having a bad time so what's one way we could offis skate that we could use the anable Vault utility so this is a command line utility baked in when you do the uh standard anable install it gives you the ability to uh kind of hash passwords right so it will kind of scramble up all that information so you can take an entire file say a file full of secrets or say it's your
View full transcriptHide full transcript
inventory file and you've got some Secret information there you can actually take that inventory file when it's file based right you're doing command line stuff and you can encrypt all of that and so at runtime on the command line you would Supply it with a password it will decrypt that information now you could also pick a specific variable inside your playbook and you could encrypt that one piece right that one variable in there as well using the uh the vating system and it is sha 256bit encryption so it's pretty pretty robust pretty hard but again you're putting encrypted or you're putting secret information into theoretically
a repository and while it may not be in decryptable now it might be in the future so I try not to put any of that information if there if I can so here's a quick example of what that same Playbook would look like I cut out the the whole task portion but for the anore password if I actually did use the Vault utility and I put it in here it kind of would look very similar to this you can see it's pretty massive right so if you're putting a lot of this inside of your playbooks it consumes a lot of space not that that's necessarily
a problem or a bad thing right but it uh it kind of definitely interrupts the flow of things so in Ascender if we do have vaulted information or vaed files uh inside of our repository we can actually go into the credential section you see here choose the credential type Vault it allows you to put in the Vault password so when you're doing it from the command line you generally are going to give the uh Das Tas like ask for password or as Vault password I can't 100% Rin the syntax but it will prompt you for the password and you can type it in and it'll
decrypt and go you can also Supply it with a file that has the password in there and then it will decrypt using that well you can do that same sort of thing you can emulate that experience in the credential section by creating a vault credential and it will decrypt that information whether it be right in your Playbook or an entire file so if you are familiar with vating you want to continue to use vating you have some very specific use case you can still do that with Ascender although it's not my favorite way of maintaining credentials so again I'm not a fan of storing secrets
in files right again you put in your SC it could accidentally get out public even if it's not easily decipherable now it might be later on right with Quantum Computing and stuff like that it could be a problem uh as well as if you're not storing secret information even if it's encrypted in files it's usually easier for auditing purpose as well as the security teams generally have fewer problems with it so it's going to make your life a little bit easier in that regard as well so you can store secrets in Ascender and I talked about it I mean it's 256 bit encryption as
well um and it can be in the credential section so if I pop into my personal uh Ascender here I can go to the credential section and I can see I have a whole host of um uh secrets in here right different credentials that are storing information you see I have some that are machine credential and that's generally going to be how I log into all of my remote servers right so it's going to be my Linux servers my windows servers uh it will be my networking appliances I'm going start typing machine it'll pop up you can see I can put in my username my
password uh SSH Keys all of that good stuff right I can actually save that in here and what that means is whenever I launch a piece of execution it's going to grab this credential and it will insert it as analore user anore password it's going to use that to log into my remote equipment so it's pretty convenient in that respect now if you look right down here um I say it's more than just servers and network appliances there's also credentials in there for say your Cloud providers and various things like that right so there's a myriad of different types built in right so your Amazon
your Google uh stuff your Google computes your Azure all that's going to be in here as well like Microsoft Azure resource manager um but what if it is a credential type you need to maintain maybe it's some special API key or some special token you need to store that you want to use in your playbook well how do I actually go about that and you can actually keep stuff in your credential store using custom credentials it allows you to securely pull any information you want from user prompt them for various things and you can inject them as either say extra vars uh or environment variables
at runtime into your playbook so if you come down to the credential type it allows you to create custom ones you can see I actually have created several in here one is my Mountain access key so for um Mountain our repository where I do LTS stuff long-term support you actually have to have an access key and so I created a custom credential that will inject that in my playbook so it's going to securely maintain that and just push it into my playbook as an extra VAR at execution time I also have generic credentials I have SSH cert uh certificate key right so if I just
want to keep a search key in here I can kind of fill in the blanks copy and paste if you look at any my blog posts uh I would say about 50% of them walk you through the process of doing all this but once you create a custom credential I can start adding credentials of various types in here so if I look at my Ascender primary using my generic credential I can click edit on this and you can see I'm just prompting for username and password nothing complex uh username is plain text here the password I marked it as secret so it doesn't matter how
many times I click the view button there right it's securely maintained and even in logging of some of my tasks it will obate that information right so if I was running that VMware um template and I was using these custom generic credentials which I actually do pretty commonly uh it will obate that it'll say no log no log on this like individual item uh due to its secret nature or whatever happens to be in there right so it'll actually help to aisc that information as well so custom credentials allow you to really develop kind of any specialized information you want to store maintain Security on
that you can inject it into your playbooks so very convenient in that respect now say for example I don't want to manually statically maintain uh Secrets inside of there right how do I actually go about that we make lots of various parts of uh automation flexible so how do we do that with secrets we use something called a Secrets engine and really a Secrets engine is just a server or a cluster of servers that sit off to the side somewhere in your environment that are queriable so your individual users your systems and so your automation will have kind of a token or a username and
password and it will connect to that Secrets engine and will ask it for things we support most of the major ERS that are out there so your Ash Corp Vault your cyber art conjure P aim uh delinia I know it as thycotic um like that plus more uh are going to be uh available to you and so ultimately what it does is whenever a piece of automation is going to be launched using a credential from a Secrets engine what it'll do is it'll stop before it actually executes anything and it will query that Secrets engine it'll pull the username password um SSH key token API
key whatever secret information like sensitive information you're storing over there it'll go and it'll pull that and it'll ually utilize it for that uh that individual execution so that could also be used with machine credentials like just how do I log into this box uh it could be yeah again API keys or tokens or any of that stuff right that's all supported and so it's also supported for um say I've got 10 hosts they're all using the same username password combo you can do that right with the machine credential it will connect and look up and do that and everything's great now you can also
do per host password lookup I've seen that in some environments I've even written a blog post that actually breaks down and shows you how to do that uh step by step using uh cyber game paths that kind of system and so ultimately what it does is it will inside of the Playbook it will query actually write a role to do it just to make it kind of reusable but it will query for each one of those individual host what's the password associated with this host it will store all that and then it's able to successfully connect to all those devices to perform whatever automation you
want hopefully that helps clear a little bit of the secrets management kind of conundrum up inside of Ascender but again Ascender awx AAP they're all functionally working the same uh if you have any questions or comments I'd love to hear them if you have any tweaks or Tunes or you do this something uh somehow different in your environment I'd love to hear from you if you're tired of counting nodes and want a better way with some awesome support give us a shout out that way too so uh Happy automating Happy uh secreting and we'll see you next time bye
Built for scale. Chosen by the world’s best.
2.75M+
Rocky Linux instances
Being used world wide
90%
Of fortune 100 companies
Use CIQ supported technologies
250k
Avg. monthly downloads
Rocky Linux
9
Enterprise products
Spanning the kernel to the orchestrator
Have questions about your infrastructure?
Talk to a CIQ engineer about Rocky Linux, HPC, and AI infrastructure.