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

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

Start by reading the salt-key behavior and master configuration described in the issue, then review the related autosign_grains_dir discussion in PR #44324. Done would include a defined design for authenticated roles, script inputs and outputs, exit codes, retry behavior, and automatic accept or reject handling.