awx
awx copied to clipboard
ansible
View playbooks in AWX
ISSUE TYPE
- Feature Idea
COMPONENT NAME
- API
- UI
SUMMARY
While playbooks should live in source control and not be edited from AWX, it could be useful to view them, especially when trying to determine what playbook a job template should use just from a filename.
Likely has some conflict with https://github.com/ansible/awx/issues/282.
ADDITIONAL INFORMATION
Added to it or in place of the above, is it possible to have a view button :eye: which will open the playbook in the actual source control interface in a new tab (github/gitlab web interface)? Just a thought! :slightly_smiling_face:
Couldn't a first relatively simple step be to add a "Browsing URL" field which could contain placeholders e.g. for branch/tag/commit name and relative path to the playbook? Together with some examples, it would allow users to construct the correct URL to the playbook, without having to hold knowledge about specific Git repos in the AWX code. Something like https://github.com/ansible/awx/blob/{{ project_branch_tag_name }}/{{ playbook_relative_path }}.
This will be problematic for access control.
People may have read access to a project in AWX, but not have access to the git repository at all. Presenting them with the contents of the repository would be a security breach.
How so? If it's a redirect to the source control hosting site, they wouldn't be able to see anything they couldn't already.
While playbooks should (...) not be edited from AWX, it could be useful to view them
I'm interpreting the above bit as AWX being in charge of the display part.
Bob does not have access to $GITREPO.
Annie creates a project in AWX pointing to $GITREPO and grants read access to the project for Bob. (or use access - more likely - Bob will be able to create JTs and still does not need to have any access to $GITREPO since the vcs credential takes care of syncing)
If AWX somehow fetches and presents the playbook to Bob, it just bypassed the security of $GITREPO.
On the other hand, if the idea is to open the location of the playbook in a new browser tab/window as per cg-gnu's suggestion, my point becomes moot. I'd rather use an external link symbol instead of an eye though, to make it more obvious that this will open some view outside AWX.
I would think it could be important to see AWX’s view of what it is running (what is on the server). Maybe even just for the site/org admins. There is potentially a difference between what Is actually running and what is thought to be running. Especially when using a requirements.yml file and external roles.
Sent with GitHawk
The argument of gforster makes sense, and I don't really follow the arguments of fvanraem (sounds to much like security by obscurity, if you can run something and see the logs, seeing the code shouldn't be security relevant or you're doing something wrong, like putting credentials in the code).
On the other hand, code is only stored temporarily locally, hence links to the local code as executed would be quickly obsolete (and "local" in a cluster is also tricky). But indeed external roles could be tricky to point to properly.
How is the playbook output currently stored? Its already reading and displaying task names. I'm not familiar with the internals, but I could imagine reading the full tasks right there. I'm imagining it gets stored in the postgres db. Maybe display the full task as an option in the modal popup as a separate tab next to JSON and standard out(currently available) or somesuch for each task. Maybe that's not the best way to display, but what I'm really speaking to is capturing the local code as executed.
I don't really follow the arguments of fvanraem (sounds to much like security by obscurity, if you can run something and see the logs, seeing the code shouldn't be security relevant or you're doing something wrong, like putting credentials in the code).
It is not about the security of the code in it's own right.
It is about by-passing a security policy that is in place at any $COMPANY. Just like AWX has its own RBAC rules, it should respect the access rules that are in place at a repository where it is fetching it's ansible jobs from.
I got your point but it's those kind of IT security rules which tell: you are allowed to run the playbook, you are allowed to see the logs, but you can't see the code, go and figure potential issues without it. This kind of thinking is corporate security non-sense and just makes the life of zillions of admins harder than it needs to be, hence it is my personal opinion that it isn't a requirement we need to consider.
So why not solve both issues (allow for controls in some company's security policy and allow viewing of the code) by leaving it up to the admin (site/org/team/whatever) to implement with the granularity they may need. It's "just" another RBAC rule.
This would be a very helpful feature.
Displaying the playbook directly in AWX does introduce complexity with security/RBAC, but adding a link to the file in Git would at least allow people to directly associate the template with the code for it. If the user doesn't have appropriate permissions to view the repo, it'd be outside of AWX's concern.
A link seems like a quick win, and future complexity of fully displaying the file in AWX could be deferred or added at a later time (with appropriate security considerations).
