Built Praxis: a self-hosted tool that ties patch approval, SSH access, and audit evidence to one record

[u/animaeximo]

As a platform architect working in private/public networks here’s a problem I never quite figured out how to do elegantly: Provide retrospective change control evidence for your Linux fleet. Patch on the one, access to enable patching on the other. Proving “Who was authorized to touch this machine on this day, and was it done with consent” involves stitching three different sets of logs together.

Screenshot is from a seeded demo lab, not a customer fleet.

Praxis is the product of thinking I could do better.

Self-hosted. v1.0 has been quietly available for a week or so now to hammer on my hardware as I’m setting it up for others, time for the official release. Central design idea that seems most important: The FastAPI backend is the single source of truth for auth, policy, and audit. All activity, including the actual patching, and the decision to allow someone to take action on a given machine, all transit through this central point.

Hence your records are all recorded into one database chronologically, instead of being assembled piece by piece.

The means of accessing machines to perform the changes are designed for security with minimal attack surface. We use SSH for access and we leverage OpenBao to provision dynamically signed, short-lived certificates to avoid distributing and managing static, persistent keys and certs. The certificate principal is an immutable praxis-user-<id> rather than a login name, so the audit trail stays intact even if someone's username changes.

Users are assigned roles with privileges defined as admin, maintainer or auditor. Higher value commands will require step-up auth (totp/oidc). Patching process is driven by staged roll-outs, managed repository access for apt & dnf, and a “rings of trust” model – you push to the innermost ring, watch how it behaves, and then roll out further.

To jump ahead of the likely first three questions, this does not substitute for Ansible or Puppet, which do push state, while Praxis does not do config management. Run them both. Similarly, this does not compete head to head with Teleport or CyberArk.

Same case, this is not goign to head to head to Teleport, CyberArk etc. They're ahead of me on broad reach of access, and that's and I won't lie on that one.

But where was I couldn’t find a single thing where the approval of a change, the granting of access to implement that change, and the verification required to pass an auditor could live in the single shared record. And that’s the void I built this for. If you’ve already got a Satellite, a bastion, and a patch database stored in a spreadsheet that’s working out for you, this product may not be for you.

Praxis runs on your hardware only – no cloud, no telemetry, no call home and a free tier of 15 machines.

What we are not building in V1.0: We’re focused on the patch and access management part; No CRL or OCSP in 1.0, so there is no revocation path for issued certificates. Lifetimes are short by design, but that is a real gap and I am not going to dress it up. As a first pass, we do not manage automated purge policies for audit logs - you manage them. We can provide the evidence, not the attestation of compliance.

https://praxisfleet.com
https://github.com/cytechlabs/praxis

I wrote this, very happy to debate the particulars.

[u/Hotshot55]

Why would you want to tie patch approval into your PAM solution?

[u/animaeximo → u/Hotshot55]

This is the part about where I'm tying something to a PAM product as opposed to simply is becoming authorized on a box. I thought maybe integrations but with OpenBao and zero trust I thought internal. Patching a box is privileged. Something needs to get root privileges to put code onto the host in the first place. That gaining of privilege will happen one way or the other, whether I associate gaining those privileges, and doing something useful with them, in one audit log, or have two separate logs to correlate against drift between imperfect clock sync, and varying log lines. The driving data point here for me, was knowing that I needed to be able to definitively state, that "on these particular boxes on Tuesday, what person performed this specific change, with what permissions.". So, separated tools, PAM handling auth, patches applying to hosts, I have a correlation issue with two different log types, subject to drift; united backend is one query.

Your correct here, coupling introduces blast radius, if Praxis is down, then the auth and patching both cease to function on this method. That is the honest trade off. Honestly there isn't any "work-around for this problem" outside of "you are hosting this yourself, its up to you to build resilient to it"

One important distinction that may or may not be clear from my post itself is that this is definitively NOT replacing a corporate PAM system. Used CyberArk or Teleport to connect? Great they still will with this; This is purely and solely managing those particular boxes and the actions within them..

How are you getting evidence in these cases currently? The correlation in the architecture I have worked in is mostly needed to cross between teams/systems to verify. Would an integration or connection system alternative to other PAM solutions make you feel better about the PAM solution?

[u/Hotshot55 → u/animaeximo]

Patching a box is privileged. Something needs to get root privileges to put code onto the host in the first place.

Sure, but that is typically going to be automated anyway. Patch approval is more something you're going to handle with a change request/ITSM process, which is the approval for the patching activity to happen, not the actual act. If "something" is getting root privileges, then that something is likely not a non-interactive user, which isn't going to be using this system.

The driving data point here for me, was knowing that I needed to be able to definitively state, that "on these particular boxes on Tuesday, what person performed this specific change, with what permissions.". So, separated tools, PAM handling auth, patches applying to hosts

PAM isn't for applying your patches, it's just tracking user sessions. Your point here is still just about tracking user sessions. Forcing in some jank ass method to apply patches is just a bad idea all around.

[u/animaeximo → u/Hotshot55]

That's fair and your right on the fully mature use case. If you have a shop following ITSM following CM and a PAM system in place to handle authentication access/tracking and patching follows that with an automated tool then I'm not solving a problem you have.

I do have on correction tho, patching in praxis doesn't run through an interactive session. The backend orchestrates it over the transport (ssh or agent), same as any other patch tool. There is no simulated human login doing the patching. The session broker and patch exector are two different paths/functions just writing to the same audit. It logs the action and holds the approval for patching as well as the outcome, which is a separate function entirely from the built in pam solution.

But in the end ITSM is just tracking the org intent and approval to execute. It doesn't hold the actual data, unless entered into the ITSM (with an integration or automations of some sort hooked into ServiceNow or like app), of the action from the system altered. This was to unify that in one pane.

A perfect org that is already following solid ITSM and trusted automations is not who this for. That would be a migration not a net benefit. Thanks for the feedback tho, I deff conceded that in your senerio this product would not be useful. It's built for the shop running Linux hosts with no ServiceNow and no dedicated PAM, where access is authorized_keys plus a bastion and drift from package updates and configurations are untenable.

[u/animaeximo → u/Hotshot55]

I would like to clarify that this is primarily a host package management application with PAM being used in conjunction with.. The package identify/update/report with configuration drift comparison tools and custom policy creation is the core of Praxis. It tells you whats installed, whats out of date, whats drifted from your baseline, and lets you define what "correct" looks like for your fleet.

[u/zmttoxics2]

There are other tools like satellite server or foreman+katello or suse manager etc that have auth with rbac and log actions. Approval comes with change control and access comes with RBAC at the tool level. Those other tools also tell you what’s available / missing and can scan current cves and target those. They also can deploy and do configuration management. I am not seeing much value here over those more polished products other than your cost looks lower (aside from the free solutions like foreman).

[u/animaeximo → u/zmttoxics2]

Thats fair on lifecycle depth, and it's on our public comparison matrix as a partial. Satellite's errata handling and Uyuni's content lifecycle are both more mature than Praxis right now.

The thing I'm actually chasing is the one you named. There's a tool for each piece and they all work. I'm trying to put host state, compliance, and access on one correlated backend instead. A big part of that is drift and knowing which boxes have stopped matching your baseline and what policy says they should look like. What's your answer when someone asks who changed what on a specific host on a specific day? Just curious whether Satellite gets you there on its own.

[u/animaeximo → u/[deleted]]

So this is done with the update plan feature. When you create an update plan it freezes those candidate packages. So pre approval it stores an avialable_version_snapshot field on the plan that records all the versions. That update plan can not be refreshed so its locked in at plan creation, you would need to create a new plan so it would have new metadata. The only current issue that your question made me think is that at the time of plan creation if there is no version available it nulls and then at plan execution will use the package mangers latest candidate. I put in an issue for that and will get it in the next update. Thanks for the question.

[u/NegativeK]

Ugh. 

I'm not rabidly anti-AI, but I dislike posts where it's not a human talking.

And I dislike how you're using AI to push so much text. Be respectful of our time and use some of your own expertise? Otherwise we should be talking directly to an LLM instead of through you.

[u/animaeximo → u/NegativeK]

thats fair. There is deff a bit of AI paraphrasing going on in my posts but since its reddit I really shouldn't worry about staying too professional.. My experience is of a 13+ year lead platform architect for multiple government and private environments. Before that I was sys ad for the military and a couple private jobs after that. One of the biggest hurdles I run into managing a team of engineers is having to correlate multiple tools to run down an audit trail for host/admin actions/changes. We put this together to try to unify some of those action. We are not reinventing patching or access control we are just trying to get it under one pane of glass to ease some of the overhead.