[Feature]: Salt-mine access restrictions / permission granularity

[ptonelli]

Problem

Salt-mine (http://docs.saltstack.com/topics/mine/index.html) is a new great tool in Salt. However, the acces to salt-mine authorization is all or nothing. A minion either has access to the mine or has no access.

Proposition

It would be really useful to have a permission mechanism which would:

• limit access for a given minion only to certains grains from other minion

and / or

• permissions to access only specific minions and not to all the infrastructure.

[basepi]

Thanks for filing this. This is a great idea, and hopefully won't be too difficult to implement. =)

[kostecky]

Is there any update on this functionality and/or status on whether it's being actively developed or toyed with?

[ptonelli]

no work for now from us at this time I am afraid.

[arnisoph]

+1 for this feature

[paul-mulvihill]

+1 for this

[lubyou]

+1 for this feature

[pierluca]

+1

[The-Loeki]

https://docs.saltstack.com/en/latest/ref/configuration/examples.html

#####         Mine settings     #####
#####################################
# Restrict mine.get access from minions. By default any minion has a full access
# to get all mine data from master cache. In acl definion below, only pcre matches
# are allowed.
# mine_get:
#   .*:
#     - .*
#
# The example below enables minion foo.example.com to get 'network.interfaces' mine
# data only, minions web* to get all network.* and disk.* mine data and all other
# minions won't get any mine data.
# mine_get:
#   foo.example.com:
#     - network.interfaces
#   web.*:
#     - network.*
#     - disk.*

[paul-mulvihill]

That does cover the first half of the request. For me personally the 2nd half of the request would be the most useful. The ability to limit the infrastructure it pulls from.
I have a different departments in my estate and a single network of salt masters.. being able to forcibly limit the results of mine queries to the minions department would be very useful (maybe via department level grain/pillar value).

[The-Loeki]

Well the docs are pretty limited, but the following oughta kinda work:

mine_get:
  mine-getters*.example.com:
    - mine-pushers*.example.com:
      - network.interfaces

[paul-mulvihill]

Would that enable the restriction on results?
Department A, Minion S1 S2 S4 S6 S8
Department B, Minion S3 S7 S9 S10

If they two servers (S1, S3) query for all minion IP's. I want S1 to only return other minions in department A (S1, S2, S4, S6, S8) and S3 to return only minions in department B (S3, S7, S9, S10).
I'm not sure it currently allows that level of restrictions but I've not looked at mines for a long time after I saw the original lack of limitation.
Unfortunately I can't have minions from other departments appearing in a minions results.
Having something I can set on the minion the forces a limitation to quires would be awesome.

[The-Loeki]

Once you set mine_get to something, that something becomes the whitelist for permissions/access.
So the example I gave gives mine-getters*.example.com exclusive mine access to network.interfaces exclusively on mine-pushers*.example.com.

Buf if I understand your setup you should be able to do something like:

mine_get:
  *.dep-a.example.com:
    -   *.dep-a.example.com:
      - network.ip_addrs6
  *.dep-b.example.com:
    -   *.dep-b.example.com:
      - network.ip_addrs6

Also note that the minion's mine call needs to use the exact same match to work.

[The-Loeki]

Update: NM, that syntax seems to work only on Publish for now :(

[paul-mulvihill]

thanks for that.. i think my setup is going to work against me.. all servers have the same naming scheme so based on that alone there isn't a differentiation.. I use the grain data to classify them.. I'll have to look and see if grain groupings can be added into the minion config and see if that works.

[The-Loeki]

Bear in mind that grains are delivered by the minions and are therefore not a good way to safely filter / pillar / group on.

[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.