Add SSL/TLS Support for Secure SaltGUI Deployment

[intekhab1025]

This PR adds comprehensive SSL/TLS support to SaltGUI with automated setup scripts, Docker Compose configuration, and Salt state management for secure deployments.
✨ Features Added
🔐 SSL/TLS Infrastructure
Self-signed certificate generation for development/testing
Docker Compose SSL environment with HTTPS endpoints
Salt state for SSL configuration (saltgui-ssl.sls)
Automated testing script for end-to-end SSL verification
📁 New Files
generate-ssl-certs.sh - SSL certificate generation script
test-ssl-deployment.sh - Automated SSL testing
docker-compose-ssl.yml - SSL-enabled Docker environment
master-ssl - Salt master configuration for SSL
saltgui-ssl.sls - Salt state for SSL deployment

[erwindon]

@intekhab1025
I would indeed be very nice to present a SSL/TLS sample setup.
But as before, I cannot support the SLS to install into any environment. It has too many fixed decisions that need changes for other environments. First of all the fixed username/password, but it applies to other setting also.

My proposal is to simplify the code, roughly like this:

• Add dockerfiles/dockerfile-saltmaster-ssl; similar to dockerfiles/dockerfile-saltmaster, but with all ssl setup steps. It should roughly contain all the logic from master-ssl and generate-ssl-certs.sh;
• Update build-and-upload.sh to include the new image;
• Add docker/docker-compose-ssl.yml. It starts the new saltmaster-ssl and the minions;
• Provide details in the documentation on how to run this using docker-compose and how to connect to it using a browser.

My further proposal is that I make these changes myself for the following reasons:

• I want to first restructure the existing docker-compose so that salt-master and salt-api become individual (and simpler) images, see split the container 'saltmaster' into a separate 'saltapi' and true 'saltmaster' #744; and
• I want to become familiar with all details of this change as I think a maintainer should; and
• I want this addition to be consistent with existing work.

[intekhab1025]

@intekhab1025 I would indeed be very nice to present a SSL/TLS sample setup. But as before, I cannot support the SLS to install into any environment. It has too many fixed decisions that need changes for other environments. First of all the fixed username/password, but it applies to other setting also.

My proposal is to simplify the code, roughly like this:

• Add dockerfiles/dockerfile-saltmaster-ssl; similar to dockerfiles/dockerfile-saltmaster, but with all ssl setup steps. It should roughly contain all the logic from master-ssl and generate-ssl-certs.sh;
• Update build-and-upload.sh to include the new image;
• Add docker/docker-compose-ssl.yml. It starts the new saltmaster-ssl and the minions;
• Provide details in the documentation on how to run this using docker-compose and how to connect to it using a browser.

My further proposal is that I make these changes myself for the following reasons:

• I want to first restructure the existing docker-compose so that salt-master and salt-api become individual (and simpler) images, see split the container 'saltmaster' into a separate 'saltapi' and true 'saltmaster' #744; and
• I want to become familiar with all details of this change as I think a maintainer should; and
• I want this addition to be consistent with existing work.

@erwindon - This makes sense, I went ahead and addressed first part of comments. Also readme has been updated with instruction.

[erwindon]

well done!

I wanted to split salt-master and salt-api in the existing docker-compose set. But I have abandoned that. These 2 really belong together and (too) much compensation is needed when you put them in different containers.
The change is now already much more consistent with the previous work.
And this change is now easy enough for me to understand.
So I'll drop the request to make the changes myself.

The review so far is only based on the text of the PR. I may add more comments/requests when I'm testing this.

[erwindon]

@intekhab1025
I still have 2 technical problems with this:

• The minions in docker-compose-ssl.yml are connecting to saltmaster-local. but the compose file defines saltmaster-local-ssl. that name may be reduced to saltmaster-local again to get this working again. note that in an earlier comment I suggested to use saltmaster-local-tls, but that specific comment is then voided.
• when I navigate to https://localhost:3334, there is no valid HTTPS service there, the SSL/TLS part fails. do you have better results?

Please also look into the remaining review comments.

[intekhab1025]

Yes will check them out, my plan is to address all by this week

[erwindon]

@intekhab1025
I've made a few changes on the master branch, some of which overlap with your work.
Can you please rebase your branch?

[erwindon]

@intekhab1025
In the mean time, I thought on how this can be easier useable.

The existing docker-compose set is used from shell script runtests.sh. But that one shuts down the compose set after the regression tests have run. So that is not convenient to demonstrate a system, whether using tls or not. Note that that was a problem you did not introduce, but the explicit presence of extra compose set strengthens the problem.

Therefore, I want to add the following 2 files:

file docker/runstd.sh:

#!/bin/sh

set -e

# start a salt master, three salt minions and saltgui to run tests on
# Don't use --detach; travis docker does not understand it
docker-compose --file docker-compose.yml up -d

# wait until user decides
echo "Please use http://localhost:3333 for SaltGUI (Username='salt', Password='salt')"
echo -n "Press ENTER to stop $0"; read dummy

# remove the containers
docker-compose --file docker-compose.yml rm --force --stop

echo "DONE!"

# End

and file docker/runtls.sh:

#!/bin/sh

set -e

# start a salt master, three salt minions and saltgui to run tests on
# Don't use --detach; travis docker does not understand it
docker-compose --file docker-compose-tls.yml up -d

# wait until user decides
echo "Please use https://localhost:3334 for SaltGUI (Username='salt', Password='salt')"
echo -n "Press ENTER to stop $0"; read dummy

# remove the containers
docker-compose --file docker-compose-tls.yml rm --force --stop

echo "DONE!"

# End

[erwindon]

Please make sure that you can run SaltGUI with TLS with your supplied docker compose file with at least the following steps:

• SaltGUI login screen shows on https://localhost:3334
• Login with salt/salt
• Go to to page Keys
• See the 3 minions

[intekhab1025]

@intekhab1025 I still have 2 technical problems with this:

• The minions in docker-compose-ssl.yml are connecting to saltmaster-local. but the compose file defines saltmaster-local-ssl. that name may be reduced to saltmaster-local again to get this working again. note that in an earlier comment I suggested to use saltmaster-local-tls, but that specific comment is then voided.
• when I navigate to https://localhost:3334, there is no valid HTTPS service there, the SSL/TLS part fails. do you have better results?

Please also look into the remaining review comments.

@erwindon - I have fixed the issue so https://localhost:3334 works now, see the attached snapshot. Also I have updated the build script to make it platform independent.

[intekhab1025]

@intekhab1025 I've made a few changes on the master branch, some of which overlap with your work. Can you please rebase your branch?

Done

[intekhab1025]

@intekhab1025 I've made a few changes on the master branch, some of which overlap with your work. Can you please rebase your branch?

[intekhab1025]

Accidentally, I closed the PR but it should be good to go now @erwindon

[erwindon]

Ok, nice work! the docker-compose-set with tls is indeed working nicely.

but I have problems with the change:

• you have merged the master branch into your development branch.
  this makes it very unclear to see which changes are really part of the new feature, and which changes that were injected in another way.
  development branches must be 'rebased' to update them (no 'merge' from main/master).
• there are too many changes on the branch that deal with non-related functionality (e.g. the salt-states). yes it is removed again in later commits, but the branch contains the full history of adding it and removing it.
• most of the changes in the build-and-upload.sh script have a different purpose than the original PR. i.e.: tls vs multi-arch.
  that is not acceptable in this PR. but I can accept a separate PR for multi-arch.
  further, you have updated that script with comments that are not descriptive to the functionality. e.g. describing what is "unchanged".

I foresee that it will take (too) many iterations to get this right.
Therefore, I intend to re-implement this PR by git-squashing your code and leaving the unrelated parts behind.

[intekhab1025]

Ok, nice work! the docker-compose-set with tls is indeed working nicely.

but I have problems with the change:

• you have merged the master branch into your development branch.
  this makes it very unclear to see which changes are really part of the new feature, and which changes that were injected in another way.
  development branches must be 'rebased' to update them (no 'merge' from main/master).
• there are too many changes on the branch that deal with non-related functionality (e.g. the salt-states). yes it is removed again in later commits, but the branch contains the full history of adding it and removing it.
• most of the changes in the build-and-upload.sh script have a different purpose than the original PR. i.e.: tls vs multi-arch.
  that is not acceptable in this PR. but I can accept a separate PR for multi-arch.
  further, you have updated that script with comments that are not descriptive to the functionality. e.g. describing what is "unchanged".

I foresee that it will take (too) many iterations to get this right. Therefore, I intend to re-implement this PR by git-squashing your code and leaving the unrelated parts behind.

I see, appreciate your help. Let me know if you would like me to instead clean up that, i can have a look tomorrow.

[intekhab1025]

Ok, nice work! the docker-compose-set with tls is indeed working nicely.

but I have problems with the change:

• you have merged the master branch into your development branch.
  this makes it very unclear to see which changes are really part of the new feature, and which changes that were injected in another way.
  development branches must be 'rebased' to update them (no 'merge' from main/master).
• there are too many changes on the branch that deal with non-related functionality (e.g. the salt-states). yes it is removed again in later commits, but the branch contains the full history of adding it and removing it.
• most of the changes in the build-and-upload.sh script have a different purpose than the original PR. i.e.: tls vs multi-arch.
  that is not acceptable in this PR. but I can accept a separate PR for multi-arch.
  further, you have updated that script with comments that are not descriptive to the functionality. e.g. describing what is "unchanged".

I foresee that it will take (too) many iterations to get this right. Therefore, I intend to re-implement this PR by git-squashing your code and leaving the unrelated parts behind.

@erwindon - I have cleaned up , squashed all commits and rebased. Please check now

[erwindon]

OK! almost there, and less work for me. just one more detail:
the indentation in build-and-upload.sh is inconsistent.
please use git amend+forcepush if you still want to fix that (not strictly needed, see below).

note that I have the following followup-changes in mind:

• update version number to 3007.6
• stop exposing ports 4505+4506 from docker-compose
  that way, it does not conflict with the regular saltstack installations
• adding the 2 files runstd.sh and runtls.sh I showed earlier
• update build-and-upload.sh to stop pushing to docker-hub and which will then be abandoned. and giving the script the new name build.sh or so.

[intekhab1025]

OK! almost there, and less work for me. just one more detail: the indentation in build-and-upload.sh is inconsistent. please use git amend+forcepush if you still want to fix that (not strictly needed, see below).

note that I have the following followup-changes in mind:

• update version number to 3007.6
• stop exposing ports 4505+4506 from docker-compose
  that way, it does not conflict with the regular saltstack installations
• adding the 2 files runstd.sh and runtls.sh I showed earlier
• update build-and-upload.sh to stop pushing to docker-hub and which will then be abandoned. and giving the script the new name build.sh or so.

Okay, good catch, fixed the indentation.
The idea of other changes sounds good. Shouldn't we consider these changes in a different PR to make this PR change consistence?

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[erwindon]

NOTE: I added the word "sample" to the merge commit

[erwindon]

@intekhab1025
thx!