Hi,
I wrote a small powershell module for Ansible. My Windows Admin wants me to use a specific configuration when connecting to the server for security. So I would like to know if Ansible can be configured to have a session initialized like this:
Enter-PSSession -ComputerName myhostname -ConfigurationName Ansible
I did some digging and found nothing.
Thanks!
Vincent
Hi Vincent
I don’t believe this is possible right now as Ansible uses an older protocol than Enter-PSSession. What is the configuration that you need to use, potentially it can be covered with different arugments.
Thanks
Jordan
Hi Jordan,
This is a custom configuration created by one of our Windows admin to control what Ansible could do on the server. Personally I have some doubts about the maintainability and the usefulness of managing these configurations since the purpose of Ansible is to configure the server… Ansible needs to have Admin right to do anything meaningful in my opinion.
Do you know if an upgrade to the protocol implementation in Ansible is on the roadmap?
Thanks,
Vincent
Yeah, this is along the lines of “constrained sudo” on the Linux side. We haven’t spent any time working on this yet, but it’s on the 2.3 roadmap to explore. I won’t say it’s impossible to make it work with a constrained configuration, but as you’ve alluded, it’s very difficult, and at least in the Linux case, you have to give so many privileges (eg, launching arbitrary processes) that the “jail” is very escapable anyway. The way we do things on Windows, I suspect the same will be true. Switching out the underlying WinRM protocol to PSRP is actually the easy part.
I’ve thought through a couple of ways that we might be able to make this work, but they’d require a lot of infrastructure that’s currently missing, so I wouldn’t count on it for at least the next couple of releases…
-Matt
Sorry, it’s on the 2.4 roadmap to explore.
I thought about this myself.
One of the nice things with constrained endpoints (which is one of the things you can do with the “configuration” option is that the connection account doesn’t have to be the same as the execution account on the server, which (imho) is an avenue that could potentially be worth exploring.
That said, I have no idea how winrm implements configurations so it probably takes a bit of research.
IIRC, each named configuration has a discrete HTTP URL, and at least for JEA (which is the recommended method), it’s PSRP-only. Jordan’s got a PSRP layer prototyped for pywinrm that we’ll likely be merging soon, so the protocol end of things is getting workable, it’s just a matter of how to sanely lock down the module stuff. My early experiments with PSRP a long time ago showed that it’d be quite a bit slower than naked WinRM, too, so we’d probably want to keep both options available unless we do some fancier connection pooling or something to cut down on the extra PSRP chatter.
I’ve been kicking around a couple of ideas on how we might be able to enable JEA sanely. The one I like the best is to build a tool that can either wrap Ansible modules directly in a rolecap PS module, or define a custom rolecap executor function that includes a list of “allowed” modules (which would need to be code-signed by Ansible or the org). In the second case, the executor runs in the unrestricted context, so would verify that the module is on the list and that the signature is valid (ie, the module code hasn’t been hacked by the caller), then run it. I like the second option better, since it’d better allow for upgrades of Ansible without updating the rolecap stuff, but securely implementing code-signing on modules in an open-source project is a big ball of wax.
Anyway, plenty of discussion to have here in the coming months…
-Matt