RFE: Minion Authenticated Roles with salt-key & Auto Accept

[damon-atkins]

Description of Issue/Question

Part A)

Example of what salt-key could look like

salt-key -L
Accepted Keys:
webserver.example.com saltenv role1,role2
Denied Keys:
Unaccepted Keys:
something.example.com saltenv role1,role2,role3 IP  
Rejected Keys:

salt-key -l debug --accept-auto --command my_auto_accept_script.new  # force a run of auto sign and override the command in the master config file

(IP address is not stored its used for auto acceptance, or give the user a bit more info)
Roles are not gains or pillars they are a new data type which can be used in a top.sls And because the master stores the roles and the saltenv with the key (pki dir or a role dir), they can be considered secure. i.e some developers may have access to the pillar dir or pillar git repo, but the roles and saltenv are safe in the pki dir (or its own dir).

Part B)

The master running a script to see if it should accept or reject, allows a person to do anything they want.
Secure or Insecure. Here are examples of what a script could do (Various levels of security):

• Check the DHCP server for PXE boot
• LDAP query to AD to see if the "COMPUTER" exists and if the IP it connect from matches. (it would require master recording IP address the connection came from)
• Reverse DNS Lookup of the IP and check the minion name against this (it would require master recording IP address the connection came from)
• AWS Query to see if it exists in AWS
• Check with a 3rd part as described above a few comments ago. e.g. RightScale, Consul, SoftLayer
• Accept any minion connecting from a list of networks.
• Just accept all

Something along the lines of command <minion id> <input data filename> <return data filename> everything else is passed as environment variables. e.g. salt conf dir, location of the minions data receive (json) by the master (e.g. grains, IP etc)
Exit Codes Returned:
10 = Accept
11 = Reject
12 = Manual i.e. let the human decide. with salt-key OR Pass it on to the next script (if more then one provided)
13 = No Decision Yet, i.e. Ask again. e.g. The data need to make a decision with, might be slow at getting populated (e.g. Windows system as not reach the stage it joins AD, or registered in consul). So script would like to be able to ask again, in a minute or two. The script can implement a count of tries and change the exit code to 12 or 11 if the re-try count is too high. The minion connecting again would be a good way to trigger auto accept script again.

<input data filename> would be a json file containing secure/verified data and insecure data like grains.
<return data filename> would be a json file allowing saltenv to be changed or the roles to be changed.

Also no reason why salt package can not include a few example scripts. e.g. autosign_grains_dir that parts of PR #44324 is talking about doing. Maybe the script can receive saltenv and roles, check them and then return final saltenv and roles (could add roles or even change the saltenv). i.e. JSON feed into the script and JSON

[gtmanfred]

@saltstack/team-core Looking for feedback on this idea?

Thanks,
Daniel

[damon-atkins]

@thatch45 gave some feedback in the PR #44324

I added roles into the accepted key process as these roles can be request by a minion but they can not be changed once accepted. And the master has alternate control to accept all, some, none or add some roles. Unlike grains these are secure, and the idea is to use them in the top.sls for states and pillars. They can also be used on the minion (sent back as pillar data)

Outstanding questions are:

1. Should you be able to update the roles or the client needs to go through the acceptance process again?
2. Should they be signed with the keys, to prevent tempering on the master?
3. Should the roles be sent back signed by the master during acceptance or be sent every time in pillar data?

[damon-atkins]

@thatch45 Can this be label for Fluorine?

[jcmcken]

Just some food for thought:

Puppet uses custom CSR attributes to attach metadata to signed agent (minion) certificates. See here.

Puppet then exposes this metadata as trusted facts that can be used to target clients (minions) in a secure way.

The lack of this feature really makes it quite difficult/cumbersome to manage a multi-tenant Saltstack environment with differing levels of privilege in a secure way.

I would hazard a guess that most people run Salt in such a way that the compromise of one node could lead to the compromise of even more nodes/components via extraction of sensitive pillar data. Almost every example you see uses (insecure) grains to target nodes for pillar data (e.g. a role grain), despite the warnings in the documentation. In my opinion, that's because there's no other easy alternative to this. Using the minion ID is simply not a scalable solution in a cloud-based world, where hostnames need to be randomly generated, and clients could have kilobytes of metadata that need to be specified to correctly target them for configuration.

TL;DR: Please implement this feature!

[rallytime]

HI @damon-atkins - we are moving towards using an RFC template, which is documented here for these types of discussions. Would you be willing to give that template and process a try?

FYI @saltstack/team-suse ^

[damon-atkins]

Leave this open until I have done the RFC

[isbm]

@damon-atkins I would suggest you to reference this issue in your RFC PR.

[damon-atkins]

.

[damon-atkins]

Some more thoughts on this are support for minion running as normal users. e.g. a 3rd party supports the OS and so Salt can not run as root and people would like to use salt still for application deployment.

Allow salt keys to also have the format of username@hostname. And then top.sls to support username@hostname.

salt-key -L
Accepted Keys:
httpd@webserver.example.com saltenv role1,role2
Denied Keys:
Unaccepted Keys:
mysql@something.example.com saltenv role1,role2,role3 IP  

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.