Description

Currently, if a Uyuni user wants to make a direct call to salt it needs to enter the console and call cli. With the new containerized release users should use the API instead and provide a cli like pepper (https://github.com/saltstack/pepper). Users should configure an external authentication mechanism to allow users to make API calls (https://docs.saltproject.io/en/latest/topics/eauth/index.html).

To make it easier, and avoid duplicating the user definition we could develop a external authentication mechanism to integrate with uyuni server users and re-use the credentials.

Accessing the API using Uyuni server credentials opens the issue of which machines users have access to. Allow users calling the API without controlling which machines they are allow to interact with is an security issue. To overcome it SUSE should also generate a publisher ACL (https://docs.saltproject.io/en/latest/ref/publisheracl.html) with rules limiting which machines the user can operate.

A possible next step could be to adapt Uyuni server code (tomcat) to authenticate to salt API with the WEB/API authenticated user and propagate that to the salt call. We would need to keep the generic admin user around for SUMA internal and automatic calls to salt API. This change would also be true for the page "salt" → "Remote Command", and get more visibility of which user makes each call.

Ideas

Define a new external authentication mechanism for uyuni, where we receive the user/password and validate that against the XMl-RPC API (or json over HTTP).

The second stage is to generate a ACL. We can look at how some others are implemented and we can have them in the configuration file, and merge that with the ones coming from uyuni server. Have a new endpoint that provide the ACL for the user. We should generated it in the fly to allow actions only in the minions the user has access to. Then we can enhance this, and allow the definition of 2 things on uyuni side for each user:

• If user can have access to salt-master API
• custom ACL, which would overwrite the default generated one. In this we can discuss if the custom ACL rules should merge with the existing ones or overwrite them? In my opinion, if the user has some custom-defined ACL's we should use only those and replace the default ones from uyuni side.

Goals

• Authenticate salt maste API using Uyuni credentials
• Publisher ACL received and generated on the fly by Uyuni

Resources

• Uyuni server
• Salt master

Update Status

Day 1

Setup test environment

- map port on uyuni server
    - On uyuni server change file `/etc/systemd/system/uyuni-server.service.d/custom.conf`
        `-p [::]:9080:9080 -p 9080:9080 `
        - `systemctl daemon-reload` and restart server service
    - on file `/etc/salt/master.d/susemanager.conf`
        - comment line `host: 127.0.0.1`

Create a test script or command that call the API using the current infra with user in file

```
curl --insecure -sS https://localhost:9080/run -H 'Accept: application/x-yaml' \
 -d eauth='file' \
 -d username='admin' \
 -d password='25e556e4cb0abfd4be47f3741a7dd3682aea53f99491445f1ee5e53ba1fc5f93' \
 -d client='local' \
 -d tgt='*' \
 -d fun='test.ping'
```

• Try to debug salt API code
  • start salt-api with debug level /usr/bin/salt-api -l debug

Create a new Authentication module to integrate with SUMA

- auth modules location: `/usr/lib/python3.6/site-packages/salt/auth`. Module is calles uyuni
     - Code: https://github.com/uyuni-project/uyuni/compare/master...rjmateus:uyuni:uyuni_hackweek_2024_salt_auth#diff-0e188365d2773d5a6bed03fd9bccb579737b5ee7bd037d8854c2fb89619e4638
- Restart salt api and master so the changes are loaded.

call all minions. No ACL set at this point, and all calls are allowed to all minions

```
curl --insecure -sS https://localhost:9080/run -H 'Accept: application/x-yaml' \
 -d eauth='uyuni' \
 -d username='admin' \
 -d password='admin' \
 -d client='local_async' \
 -d tgt='*' \
 -d fun='test.ping'
```

Day 2

Improve authentication module with ACL

• Improve the salt authentication module with ACL dynamically generated on Uyuni server
  • code: https://github.com/uyuni-project/uyuni/compare/master...rjmateus:uyuni:uyunihackweek2024saltauth#diff-2971ef736105935bf78069ba43a380406deb35417f23aa5b9357e90f47f1374a

Fail call: do not allow wildcard

```
curl --insecure -sS https://localhost:9080/run -H 'Accept: application/x-yaml' \
 -d eauth='uyuni' \
 -d username='admin' \
 -d password='admin' \
 -d client='local_async' \
 -d tgt='*' \
 -d fun='test.ping'
```

Call success; we must pass the exact minion. This is because the acl is defined in away that is allowing minion by minion.

```
curl --insecure -sS https://localhost:9080/run -H 'Accept: application/x-yaml' \
 -d eauth='uyuni' \
 -d username='ricardo' \
 -d password='ricardo' \
 -d client='local' \
 -d tgt='uyuni-minion2.suse.lab' \
 -d fun='test.ping'
```

Integration with pepper

• https://github.com/saltstack/pepper

Installed it on a second machine, and be able to call salt commands using pepper.

Need to add the following property to the salt master configuration: keep_acl_in_token: True https://docs.saltproject.io/en/latest/ref/configuration/master.html#keep-acl-in-token

From the machine run:

pepper -v --client=local -E -u https://uyuni-server.suse.lab:9080 -a uyuni --username=admin --password=admin 'uyuni-minion.suse.lab' test.ping

Alternative way to run:

export SALTAPI_USER=ricardo SALTAPI_PASS=ricardo SALTAPI_EAUTH=uyuni SALTAPI_URL=https://uyuni-server:9080/

pepper 'uyuni-minion.suse.lab' test.ping

Pepper was properly working, and was able to call salt command from the outside machine.