AWX in Action

The Object Model in One Page

You've created organizations, users, and teams. Those are the access-control layer. Now meet the resources they'll work with.

When you create resources in AWX (projects, inventories, and so on), you should typically add them to an organization.

Every object in the table above gets touched in that flow. Hosts, inventories, projects, credentials, and job templates all sit inside organizations, and access to them is controlled by roles you grant to users or teams.

Two ways to give someone access to a resource:

• Directly to a user: For example, a user can be granted permission to update an inventory.
• To a team: The same permission can be granted to a team instead, in which case every team member inherits it.

When a user logs in to AWX, they see only the organizations and teams they belong to, and only the resources their roles grant them access to.

For example, if you want to set some permissions for a team like SolaraDev, you should click on Teams -> SolaraDev -> Roles. Here you can add or remove permissions on resources for the team.

These are the choices available for resources:

• Job templates
• Workflow templates
• Credentials
• Inventories
• Projects
• Organization
• Inventory Groups

For each of these resources, you can assign different permissions to the team. Available permissions depend on the resource.

For example, to fine-tune what a team can do within its organization, choose Organization and select the permissions you want to assign. These are some of the permissions available:

• Execute: Can run any executable resources in the organization like jobs.
• Project Admin: Can manage all projects of the organization.
• Inventory Admin: Can manage all inventories of the organization.
• Credential Admin: Can manage all credentials of the organization.
• Workflow Admin: Can manage all workflows of the organization.
• Notification Admin: Can manage all notifications of the organization.
• Job Template Admin: Can manage all job templates of the organization.
• Execution Environment Admin: Can manage all execution environments of the organization.
• Auditor: Can view all aspects of the organization.
• Read: May view settings for the organization.
• Approve: Can approve or deny a workflow approval node.

Note that the same operation (granting permissions to resources) can be done individually for a single user (User > Roles > Add).

What we call a role here is a permission grant on a resource. For example:

• Updating an inventory.
• Reading a project.
• And so on.

We haven't created many resources yet, so your understanding of the object model may be limited at this point. That's okay.

There are some high-level concepts you will get familiar with in the next modules. Here's a quick summary:

• A User belongs to one or more Organizations. They get a user type (Normal, System Auditor, or System Administrator) that controls system-wide access.

• A Team is a group of Users within an Organization. When you add a User to a Team