Bug 2215453
| Summary: | Ansible variable override behaves differently with default Remote Execution User role | ||
|---|---|---|---|
| Product: | Red Hat Satellite | Reporter: | Nagoor Shaik <nshaik> |
| Component: | Users & Roles | Assignee: | Adam Lazik <alazik> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Satellite QE Team <sat-qe-bz-list> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.13.1 | CC: | alazik, apetrova, aruzicka, balducci, mhulan, oezr, rlavi, swachira |
| Target Milestone: | Unspecified | Keywords: | Documentation, Triaged |
| Target Release: | Unused | Flags: | nshaik:
needinfo-
alazik: needinfo- |
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2024-03-25 11:06:41 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Exposing values of parameters to users who don't have permissions to see them, even indirectly, could be considered a security issue. The same could be said about giving the users permissions to see all parameters by default. I'd suggest being explicit about what the users can and cannot see and setting up their permissions accordingly. With that being said, I believe the current behavior is correct and I'd lean towards just documenting it or closing this BZ right away. Would you agree? Hi Adam, Shouldn't an error/warning be displayed if trying to schedule an Ansible run when the user doesn't have permission to view all the data to run it correctly? We cannot make any assumptions about whether something the user cannot see is needed or not. Also looking at the things the user cannot see and then displaying a warning that there's something they cannot see feels wrong. Hello! Created PR with the added warning: https://github.com/theforeman/foreman-documentation/pull/2839 Hello,
I am unable to reproduce this behaviour on foreman 3.5 and foreman 3.9. Here is what I did:
1. I created the role as described:
# cd /etc/ansible/roles
# ansible-galaxy init demo-bz-2215453
- Role demo-bz-2215453 was created successfully
# vim demo-bz-2215453/tasks/main.yml
# cat demo-bz-2215453/tasks/main.yml
---
- name: Debug
ansible.builtin.debug:
var: test_variable
# vim demo-bz-2215453/defaults/main.yml
# cat demo-bz-2215453/defaults/main.yml
---
test_variable: value_from_defaults
2. I imported the role as an admin user
3. still as an admin user I created a user called "rexuser"
- in the "authorized by" field I chose "internal" (I don't expect this to make any difference)
- for location and organization I assigned ones to which the host belongs
- under roles I left the "administrator" box unchecked and selected "Remote Execution User"
4. still as an admin, I went to Configure -> Ansible -> Variables
- I added a matcher to the test_variable with:
- attribute type: fqdn
- hostname of my test host
- as a value I set "value_from_admin_matcher"
5. I made sure to assign the demo-bz-2215453 role to my test host
6. I logged out and relogged in as the "rexuser" user
7. I launched the job by:
- selecting my test host under all hosts
- selecting Run Ansible roles
In the output I see the overridden value which was set by the admin.
Do you have any idea about what I might be doing differently? Could you maybe check again?
Thank you very much in advance.
Hi, sorry, I finally got around to looking into this with @alazik. In this BZ, I based everything I said on what was said in #0, however #0 describes a slightly different situation than what is described in the attached customer case. #0 talks about using a FQDN as a matcher type, while in the case they match on a host parameter. What was described in #9 (and #0) indeed works out of the box without any extra permissions. For the other case, if the user can't see the parameter, then the parameter-based matcher won't match. We'll adjust the docs, sorry about the confusion. Created new PR to reflect this: https://github.com/theforeman/foreman-documentation/pull/2885 A new prerequisite has been added to warn users about necessary permissions: 6.14: https://access.redhat.com/documentation/en-us/red_hat_satellite/6.14/html-single/managing_configurations_using_ansible_integration_in_red_hat_satellite/index#Overriding_Ansible_Variables_in_satellite_ansible 6.13: https://access.redhat.com/documentation/en-us/red_hat_satellite/6.13/html-single/managing_configurations_using_ansible_integration_in_red_hat_satellite/index#Overriding_Ansible_Variables_in_satellite_ansible 6.12: https://access.redhat.com/documentation/en-us/red_hat_satellite/6.12/html-single/managing_configurations_using_ansible_integration_in_red_hat_satellite/index#Overriding_Ansible_Variables_in_satellite_ansible |
Description of problem: Ansible variable override behaves differently with default Remote Execution User role when compared with the admin user Version-Release number of selected component (if applicable): Satellite 6.13 How reproducible: 100% Steps to Reproduce: 1. Create a dummy ansible role and import into Satellite # cd /etc/ansible/roles # ansible-galaxy init demo # vi demo/defaults/main.yml --- message: 'Default Value' # vi demo/tasks/main.yml --- - name: Copy file copy: dest: /root/file.txt content: "{{ message }}" 2. Over-ride the ansible variable for a hostname client.example.com to something else Configure > Variables > click on the "message" variable > click on "Override" checkbox > Add matcher > attribute type : FQDN = client.example.com and specify a over-ride value "Override Value" 3. Create a rexuser and associate it with the "Remote Execution User" 4. Now login with the "rexuser" and run the Ansible role, the message value should match with the over-ride, however the value is set to the default value. Actual results: Override behaves differently with default REX role and admin roles Expected results: Why these additional permissions are required when a matcher is set, if its required the default REX User role should be modified accordingly Additional info: When you add additional permission filter as below Ansible Role: "view_ansible_roles" Ansible Variable: "view_ansible_variable" Parameter: "view_params" After adding this the variables are correctly over-ride as per matchers.