avoid sharing keys in a multi master setup

[bruno binet]

Hi,

I'm in the process of setting up all salt minions with two masters:

- a global master, which can control every minions;

- a local master (on localhost, running side by side with salt-minion), which will allow to leverage salt-api to control the current minion through a simple web application.

So, I've gone through the multimaster tutorial, but I'm not inclined to share the same private/public keys for all salt masters as described in:
http://docs.saltstack.com/en/latest/topics/tutorials/multimaster.html#prepping-a-redundant-master

I would like to have different keys for the local master and the global master, so that a minion don't know the private key of the global salt master.

Any idea how I could avoid sharing these keys?

Do you know if patching salt in such a way would be doable? Any guidance would be appreciated.

Thanks,

Bruno

[Volker]

On 6/18/14 10:51 AM, bruno binet wrote:
> Hi,

>
> So, I've gone through the multimaster tutorial, but I'm not
> inclined to share the same private/public keys for all salt masters
> as described in:
> http://docs.saltstack.com/en/latest/topics/tutorials/multimaster.html#prepping-a-redundant-master
>
>

Currently its not possible to have multiple masters for a single
minion without sharing the masters key/priv-key and the AES-key in
some way through nfs, copying it on restart, or whatever other
possiblity there might be.

But:
I'm working on it! :-)

Current status is:

- minion supports defining multiple masters
- minion supports trying one master after the other
- minion supports randomizing the list of masters
- the minion can detect changes in the connection to its master and
act on connect/disconnect and can for example jump to next master if
it current masters connection died
- the master supports a maximum number of minions and the minion can
try the next master if one master says its full

Todo:
Have the minion support multiple master keys. That is the root of
getting all this to work.

I'm currently in the process of doing that. It will probably rely on
having a a key-pair on the master that is used for signing the keys
and the same key-pair on the minion to verify master keys.

Once that is done, multiple masters will be working! :-)

-v

[bruno binet]

Thanks, that's good news.

On 18 June 2014 11:59, Volker <g...@schwicking.de> wrote:

On 6/18/14 10:51 AM, bruno binet wrote:
> Hi,

>
> So, I've gone through the multimaster tutorial, but I'm not
> inclined to share the same private/public keys for all salt masters
> as described in:
> http://docs.saltstack.com/en/latest/topics/tutorials/multimaster.html#prepping-a-redundant-master
>
>

Currently its not possible to have multiple masters for a single
minion without sharing the masters key/priv-key and the AES-key in
some way through nfs, copying it on restart, or whatever other
possiblity there might be.

But:
I'm working on it! :-)

Current status is:

- minion supports defining multiple masters
- minion supports trying one master after the other
- minion supports randomizing the list of masters
- the minion can detect changes in the connection to its master and
act on connect/disconnect and can for example jump to next master if
it current masters connection died
- the master supports a maximum number of minions and the minion can
try the next master if one master says its full

I also need a minion to be connected to multiple masters at the same time: will it be supported?

My use case is that one of the masters will be local and used only for its ability to run the salt-api, so I need to be able to send salt commands from both masters.

 

Todo:
Have the minion support multiple master keys. That is the root of
getting all this to work.

I'm currently in the process of doing that. It will probably rely on
having a a key-pair on the master that is used for signing the keys
and the same key-pair on the minion to verify master keys.

I'm not sure I follow you here: why a key-pair to sign keys?
does it mean we can have different keys for all masters so that each master won't share their private-key with other masters?

 

Once that is done, multiple masters will be working! :-)

That's great. Please don't hesitate to ask if I can be of any help.

Bruno

 

-v







--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[viq]

On Wed, Jun 18, 2014 at 10:51 AM, bruno binet <bruno...@gmail.com> wrote:
> Hi,
>
> I'm in the process of setting up all salt minions with two masters:
> - a global master, which can control every minions;
> - a local master (on localhost, running side by side with salt-minion),
> which will allow to leverage salt-api to control the current minion through
> a simple web application.

Maybe what you're looking for is a syndic?
--
viq

[Volker]

> I also need a minion to be connected to multiple masters at the
> same time: will it be supported?

I'll keep that use-case in the back of my head.

> I'm not sure I follow you here: why a key-pair to sign keys? does
> it mean we can have different keys for all masters so that each
> master won't share their private-key with other masters?
>

https://salt.readthedocs.org/en/v0.12.1/topics/specs/salt_auth_proto_abs.html


If you're already familiar with salt communication process, never mind
that link. If you're not, it will hopefully make my approach easier to
understand.

###

Currently a minion can only have one single master public key in
/etc/salt/pki/minion/minion_master.pub. If a minion was connected to a
master and then connects to the same or any other master and receives
a pubkey that differs from the one already present on the minion, the
minion complains and exits. Its currently not possible to update a
masters pubkey on the minion.

If you have multiple masters and dont share keys, all masters will
have a different priv/pub key-pair. So if the minion switches to a
different master than it was connected to before, the master will send
a different pub-key to the minion. Therfore making the minion complain
and exit.

The comparison that is currently in the minion is very simple (pseudo):

1. connect to master
2. receive pubkey
3. read (possibly) already present master-pubkey from file
3. if pubkey not yet present, save received pubkey and continue
3. if pubkey already present, compare and complain when different

My approach is to not rely on a simple comparison like that.

I want the minion to be able to verify any pubkey from any master that
is running in my environment. That can be done by creating a new
priv/pub-key-pair on the master just for signing, make that key-pair
available on all masters and minions and then always have the master
sign its public key when it is send to a minion.

That signing key-pair only needs to be generated the first time the
master starts. It should then be included in the bootstrap process of
a minion.

Does that make it more clear?

-felskrone

[Volker]

>
> Does that make it more clear?
>

more details and place for comments and discussion:

https://github.com/saltstack/salt/pull/13570

- felskrone

[Glenn E. Bailey III]

I also need a minion to be connected to multiple masters at the same time: will it be supported?

My use case is that one of the masters will be local and used only for its ability to run the salt-api, so I need to be able to send salt commands from both masters.

Here's my HA setup for using the salt-api:

- Running two masters, well say master1 and master2

- All minions point to both masters

- Both masters are running salt-api under lighttpd

- I have a VIP that round robins to both master1 and master2

- All API calls then come into the VIP

- Send all commands async

- Use saltutil.find_cached_job via API to get job results so it'll pull from minion and not master, (which is why I wrote it) ;-)

--

"replicants are like any other machine. They're either a benefit or a hazard. If they're a benefit, it's not my problem."

[bruno binet]

Yeah, I just had a look to the salt-syndic, and it looks interesting.

But, it seems that we have to sync the salt-master states tree on the syndic to get it working. I'd like not to do that because I'd like to use the syndic as a transparent proxy to the local minion only. If I set up a salt syndic locally without any states tree, I won't be able to run the state.highstate function from the global salt-master isn't it?

[bruno binet]

Thanks felskrone for your explanations.

I think I got it: you mean the master public key is never used by the minion (except to check that the master has not changed) so we don't need to store it anymore, but use instead a shared key-pair to check that this master is known by the minion?

[Volker]

On 6/24/14 4:28 PM, bruno binet wrote:
> Thanks felskrone for your explanations.
> I think I got it: you mean the master public key is never used by the
> minion (except to check that the master has not changed) so we don't
> need to store it anymore, but use instead a shared key-pair to check
> that this master is known by the minion?
>

That is correct, except for the delete part. You should not delete any
keys generated by the maste.

Also: the secondary keypair does not replace anything. Its used for
verifying only, so a minion knows, that the pubkey it has received from
any master is from a valid master and not some hostile random masters
pubkey.

-felskrone

[Jin Nguyen]

Sorry binet, would you mind if I ask a question on your topic?


I'm learning SaltStack and I have a hesitate about Multi-Master-PKI Tutorial With Failover in:
http://docs.saltstack.com/en/latest/topics/tutorials/multimaster_pki.html

It said that set the value

master_sign_pubkey: True

but I cant find this in master configuration file at /etc/salt/master

I added this line at bottom of the file and restart salt-master but it do not generate any new key:

master_sign.pub
master_sign.pem

[bruno binet]

I think this is not available yet: will be in 2014.7 release.

Cheers,

Bruno