Transitioning authentication and authorization (RBAC) to the new AWX architecture

Project Discussions
, , ,
1

Hi everyone

We’re continuing our journey toward a pluggable, services-oriented architecture for AWX and want to make you aware of changes that Red Hat engineering teams plan to make with external authentication and Role-Based Access Control (RBAC).

As we mentioned previously, the new AWX architecture is designed to allow for code reuse across projects. The new pluggable architecture is also intended to minimize existing duplication of effort and decrease complexity for contributors. The changes we are sharing in this post builds on work we previously shared and, hopefully, brings the vision for the new AWX architecture into better focus.

Upcoming changes

Now that the Ansible UI and inventory and credentials plugins have moved to the new architecture, Red Hat Engineering is working on the following components:

  • External authentication: All external authentication methods are moving to the ansible/django-ansible-base repository. Legacy external authentication code will be removed from the AWX repository except for basic (username/password) authentication.
  • RBAC: Legacy role system RBAC functionality has been replaced by permissions-based Django Ansible Base roles. The API endpoints for the legacy RBAC implementation will be removed from the AWX repository.

Impact to upstream users

It’s important to be clear about how these changes affect AWX. All code for authentication functionality and most code for authorization (RBAC) functionality is moving to a separate repository, ansible/django-ansible-base.

  • The AWX repository will contain code for basic (username/password) authentication only.
  • When the engineering work is complete, authentication functionality will no longer be integrated directly with AWX. Community projects built from AWX source will need to maintain their own integration if they require authentication functionality.
  • Tooling or scripts that depend on these authentication methods will need to be updated to use basic authentication.
  • Any custom scripts that use the deprecated RBAC endpoints will also need to be updated.

For the AWX operator, external authentication settings are now deprecated and will soon be removed from source.

Digging deeper on external authentication

Modern services-based architectures typically use a common authentication layer for multiple services, instead of separate authentication mechanisms per service. To achieve this with Ansible projects, Red Hat engineering teams have been working on authentication mechanisms in the ansible/django-ansible-base repository.

Now that the work in that ansible/django-ansible-base repository is ready, it is time to remove the duplicate code from the AWX repository. This means that the source code for most authentication methods will be removed from the ansible/awx repository, including:

  • LDAP
  • Oauth2
  • RADIUS
  • SSO (including Azure, GitHub, Google, OIDC, and SAML)
  • TACACS+

We will also remove the AWX SSO app that is used for OAuth authentication and the legacy AWX OAuth provider.

Digging deeper on authorization (RBAC)

In the same way that having a set of shared authentication mechanisms for Ansible projects makes sense, so does creating a shared codebase for RBAC capabilities.

Consider Event-Driven Ansible (EDA), where roles with granular permissions are often needed to consume messages from message queues, respond to API calls, or process data from monitoring systems. If RBAC code exists only in the AWX repository, then it increases complexity for the EDA project team. At the same time, having RBAC code exist in both the EDA and AWX repositories creates duplication that increases maintenance overhead. As we’ve been saying all along in this series of posts, these are obstacles that we want to remove.

We have already moved a significant portion of RBAC code to ansible/django-ansible-base. The role system was replaced with permissions-based Django Ansible Base roles, which deprecated the legacy role system. Our next step is to remove the deprecated code and associated endpoints, leaving only the permissions-based RBAC functionality that was implemented alongside the legacy roles system. As noted in the Impact to upstream users section, you will need to update any custom scripts that depend on the deprecated endpoints.

Summary

We’re moving code for all external authentication integration (except for Basic Auth) and RBAC functionality to a new project. These changes will result in a dramatically slimmed down codebase in the AWX repository, which should make it much easier for contributors to navigate. These changes are also another big step towards a more modern, service-based architecture for AWX. However, these changes also mean functionality for authentication and legacy roles authorization will no longer be directly included with the AWX project.

Stay updated by joining the Ansible Forum, following the News & Announcements and awx-modernization tags.

Thank you for your continued support.

Links in this AWX update series

Useful links

5 Likes
2

Looks good, but also a bit breaking.

In the past I used the awx docker compose to test stuff (custom credential plugin). I haven’t touched it since the modernisation. If the modernisation is complete, what would be the guide to have a full all plugins/apps/libs. Looks like just the dab container needs to be running.

Can I test this now?
Scrolling (very fast) trough the docs it feels like IKEA without the manual.

@gwmngilfen: cfgmgmt camp has a call for papers. I suspect the modernisation will be a talk? But a “build awx and integrate django-ansible-base and future plugins” would be appreciated if you can find some one to give the talk.

4 Likes
3

@MalfuncEddie Hey! This is great timing and an excellent suggestion. I just announced on the bullhorn that the CFP is open for CfgMgmtCamp and would not be at all surprised if we hear about the modernisation work. In fact, I’m expecting there to be at least one session if not more.

I’m personally helping to organise things with CfgMgmtCamp this go around and can let you know when the dust settles and proposals are accepted and the schedule starts coming together. It might be a bit premature to discuss that right now though. You know how it is, there is a tendency to procrastinate with submitting proposals until the eleventh hour. Until then, you can join the topic on CfgMgmtCamp 2025 in the forum. Cheers.

3 Likes
4

Hi MalfuncEddie,

To answer your question as best as I can right now, there’s a lot of more work to be done.

So far we are mostly moving code around and solving dependencies problems and aren’t really at the point of doing much testing. It is really good to hear that there is already an interest in running tests with things like the credentials plugins though. One thing I would personally like to see from this work is replicating the successes of the migration to Ansible Collections. Such as dedicated repo, targeted CI for the 3rd party integration, new sanity tests, etc.

If you have the time for it, could you describe what you’d see as an ideal outcome for testing? I’m not in a position to make any promises about what we can deliver but it is always beneficial to hear opinions and consider other perspectives.

5

If you have the time for it, could you describe what you’d see as an ideal outcome for testing? I’m not in a position to make any promises about what we can deliver but it is always beneficial to hear opinions and consider other perspectives.

If you look at several components of AWX you have (to name a few) Receptor nodes, execution environments (with builder), ansible-runner, EDA …

All these items have great documentation on their own workings, but how it all fits together was not evident to me a couple of years ago. It was not till I found

that it all started to make sense.
This is a great piece of documentation.

The fear is that with splitting up things that are currently in awx to seperate repo’s (that I totally understand) the big picture is lost how stuff works together.

eg:

I understand the words but if I were to spin up a new test env how do you implement this?
If in the future a new release of AWX is released → How do I add authentication method XXX again? How do I limit a user to only execute templates it has the right permission on?

But like you said “there’s a lot of more work to be done” and will probably be figured out/documented in the future.

*sorry for rambling

7 Likes