1. Home
  2. Training Library
  3. DevOps
  4. DevOps Courses
  5. Ansible Basics - Automation Technical Overview

Role-Based Access Control

Developed with
Red Hat

The course is part of this learning path

Start course
Overview
Difficulty
Beginner
Duration
2h 47m
Students
508
Ratings
5/5
starstarstarstarstar
Description

This course looks at the Ansible Automation Platform. We'll look at how it works, looking at all the components like modules, tasks, and playbooks. We're going to show Ansible commands and how to use the command line tool, Ansible Navigator. You'll also learn about variables, templates and playbook basics. 

Then we'll move on to the automation controller, the web UI and API, and you'll learn where it fits in and who would be using it. We'll also take a look at some enterprise features like Role-based Access Control and workflows.

Learning Objectives

  • Learn the basics of Ansible including its components including modules, tasks, and playbooks
  • Understand Ansible commands and how to use Ansible navigator
  • Learn how to use variables and templates
  • Use Ansible's web UI and API, known as Automation Controller
  • Learn how to build a job template
  • Understand how to use Role-based Access Control and workflows

Intended Audience

This course is intended for anyone who wants to learn more about the Ansible Automation Platform in order to operationalize and put their Ansible workloads into production.

Prerequisites

To get the most out of this course, you should have some knowledge of Linux or Red Hat Enterprise Linux. Existing knowledge of Ansible would be beneficial but not essential.

Transcript

So let's talk about Role-based access control. So who can run what automation, on what inventory, with what credentials, becomes increasingly important as you scale up automation and enterprise. So we can group, teams or users into 3 different groups. So we'll kind of explain on the next slide and what that means? And these rights can be assigned across all different objects. So this user could have access to this credential, but not that job template. Or this team has access to this particular inventory, but not that inventory. And all of this can be backed by enterprise authentication if needed. Meaning that these teams could be imported from like an LDAP or Azure Active Directory or whatever you happen to be using within your organization.

So the 3 kind of levels we have with an automation platform or organization, which is unfortunate sometimes to me because I kind of refer to like a business unit within a company isn't an organization. Sometimes I have to clarify if I'm meaning more of the abstract term organization or the specific term within automation controller. An organization is a just a logical collection of users. It's just the highest level grouping we have within Ansible Automation Platform. We then have teams. It is almost but teams in our organizations, except teams are not required. They allow you to sub-divide an organization, but they're not actually required. You could put users directly into an organization, but you don't need to necessarily have a team. It just allows you to sub-divide the organization. And then obviously the lowest one is a user. These users can have different roles.

So I can have a user that is like an admin user or just a normal user that we assigned to a group and then they inherit the, the role-based access control that, particular team or that organization. So it's a lot to take in. So again, let's move into a practical example and I will show what this looks like on automation controller. There's going to be fairly a simple exercise here is we're going to make, I have a bunch of users in here, but we'll make it a user. So make a user we'll make him, Jim, I'll make it really simple. No particular reason I chose Jim. I just thought it would be a good one. Nameless. Jim. The password, we need a password. I'll just make it a password because that's super cool. We'll make this Default. And this is a Normal User. And I need the password can match or would be red. We'll click Save. So don't want my last past credential management.

So in here I'm going to take a random job, maybe one of the ones we just made. So we'll show the Apache job. And we're going to give access to Jim. You can see all those users are loaded in here and we can search. So we're going to give them the ability we have kind of a breakdown of Read. And it can just look at it. Admin, it can manage all aspects, meaning they can edit that job template and change it, or they can just execute it. So we'll just go ahead and say that Execute it. So this user jim, can execute it. So we're going to log out. We're going to login as jim and you'll see that jim shows up in the top, User Details. And we look at Templates, there's only one Job Template now. And if I click on that Job Template, I don't have an edit option. I can see who can access it. I can add Schedules, which we haven't talked about, but that's just saying like when we could run a job.

So you could run it every hour or every every day or once a month? I can see when that Job run, I can view the Surveys if there happened to be one. But I can't make templates. I can't even edit the template I have access to. So by default, users are not given access to anything, you have to kind of implicitly tell them what they get access to and what to runoff. I also can't see anything outside of my team and my users in my organization. So I'm not going to go too much more into RBAC but it basically allows you to kind of assign and unassign what that particular user, team or organization has access to.

So I'll log back in as the admin user. And you can see how different that experience is. I get access to everything because I'm the admin. I can kind of lock this down by teams and groups. So I can actually see, let's see the network group we'll go in here. I might have set these up. Cisco was just filled by network and see that it is filter. It's not for a specific job. So these are accessed by network-admin. It should be the same password. So we will look at users, we'll say network-admin just as username. I think it's the same password, and you see he only has access to the network jobs. And if we look at the Inventories as the same inventory, but this could be locked down to only network nodes.

I didn't do that for this particular example because I'm just looking at job templates. But this is a way you can start sorting who has access to what gear when you're using the same Ansible Automation Platform cluster. Allows you to kind of break this into different groups and users and teams. Now the advantage of teams and organizations is I don't have to like deviate down by user, like user by user. So if I had 500 users, I wanted to assign to be able to run the job. I could just assign it to a team, import that team from LDAP and then assign it to the particular teams and Associate that job with it. So with that, let's move back into the slides and we will discuss workflows, which I think is one of the killer features of automation controller.

About the Author
Students
106789
Labs
59
Courses
113
Learning Paths
91

Jeremy is a Content Lead Architect and DevOps SME here at Cloud Academy where he specializes in developing DevOps technical training documentation.

He has a strong background in software engineering, and has been coding with various languages, frameworks, and systems for the past 25+ years. In recent times, Jeremy has been focused on DevOps, Cloud (AWS, GCP, Azure), Security, Kubernetes, and Machine Learning.

Jeremy holds professional certifications for AWS, GCP, Terraform, Kubernetes (CKA, CKAD, CKS).