accountAddPersonalAccess pub key not added to remote server ? about the-bastion HOT 2 OPEN

Hey,

This is briefly explained in the documentation here: https://ovh.github.io/the-bastion/using/basics/first_steps.html#setting-up-access-to-a-server
If you did read it and it wasn't clear enough regarding the interaction of The Bastion and the remote server's authorized_keys files, then I'm interested to know because it means that I have to be more specific on this part!

Generally speaking, The Bastion will never connect to remote servers and "do stuff" behind your back, this has been a design principle since the beginning. This means that your remote authorized_keys need to be managed manually (or, actually using the same system that you probably already use to manage your servers configuration in a centralized way, such as Puppet, Chef, Ansible, you name it).

The logic behind this, is that The Bastion, by default, has no implicit superpower over your whole infrastructure. It only has the power you give to it, i.e. the public keys you'll add to your remote servers. Having the remote authorized_keys managed by the bastion would mean that it already has access to the remote server in some way, or it couldn't be able to modify the authorized_keys in the first place.

This design principle also means that you can setup bastion clusters to be "self-service" for your teams, i.e. you can allow commands such a selfAddPersonalAccess to all accounts, so that they can self-declare their own accesses to servers they manage. This is not a security problem because, for the access to actually work, it also needs to have the proper bastion key in the remote authorized_keys file, and if this is the case, it implicitly means that an admin of this remote server did allow it (because they added the key there, using an access they previously had).

Now, to give some perspective about the day to day usage, we usually manage authorized_keys with Puppet (but any other similar system is okay, of course), and use groups a lot, because then we can manage the egress keys in Puppet, and it doesn't depend on "who" actually has access to the groups: we don't need to modify the authorized_keys after the server has been setup, as who should have access in the end is determined by their group membership on the bastion.

Does that shed some light?

from the-bastion.

Thank for clarifying.

I understand the idea with Puppet and other tools, we manage it that way too with ansible for now, but I though it would be better to delegate this to The Bastion as the person in charge with managing access may not be the same than the one who perform tasks with Ansible/Puppets.
Also, if it manage the keys and ACL, so it is also in the best position to administer them on the remote servers, if the 2 are managed separately, then, there is a risk of keeping expired keys ad-vitam aeternam on the servers (especially in the case of personaAccess) and messing with the authorized_keys.
It would be great to have an option to explicitly "push/remove" the key as well so there is no stuff done behind our back.

Actually what I understood from that part of the documentation was that, you had to setup a first access the remote server to allow its management from The Bastion (because we are stile in the setup part of the process, adding a server to the Bastion as an admin, not giving access to other accounts/groups)
The section begins with :

This section assumes that you've just set up your bastion and your account is the one that has been created on installation, with all the super-powers included, especially access to the restricted selfAddPersonalAccess command that we'll use below...

This accentuates the idea that we are in a setup phase in admin mode and that it will not be necessary to redo the manipulation for each group/account.
There may be a few examples missing in the "access management" chapter on the creation of user/group and the addition of server access, this would surely avoid this confusion.
Also maybe the command itself could return a warning that the key is not added automatically, for now it just says to add it to the authorized_keys, but if believed it would take care of it then we say that there is a bug or a config error

from the-bastion.