How to restrict ssh connection to jenkins users?

In the scheme without the participation of Jenkins, this issue is resolved quite simply:

• Each user has a name and an SSH key.
• An account with this name has been created on each host and the public part of the key for users who can access this host has /home/username/.ssh/authorized_keys added to /home/username/.ssh/authorized_keys . Or, in extreme cases, there is one for all users and he has all public keys in ~/.ssh/authorized_keys .

With Jenkins, this scheme breaks down: there are simply no accounts for each user. All tasks are performed under the user jenkins (about the exact name of the risk to lie, double-check). Therefore, to distinguish between users, in any case, we will need to obtain the name of the user who launched the assembly directly in the assembly code. It seems that by default there is no such environment variable, but the Build User Vars plugin, for example, adds it. With it we have a BUILD_USER_ID . Such solutions come to mind. Surely there is something better, perhaps there is a special plugin - so do not take it as a guide or a guarantee of reliability, security or anything else.

1. SSH solution

   You can put the private keys of all users somewhere on Jenkins, and when performing tasks, access them:

    ssh ${BUILD_USER_ID}@hostname -i path/to/${BUILD_USER_ID}/id_rsa ... ansible-playbook --private-key=path/to/${BUILD_USER_ID}/id_rsa -u ${{BUILD_USER_ID}} ... 

   There is a significant drawback: you will store Jenkins private keys, which is no different to security. It can be quite easy to access them from some other task.

2. Software solution

   You can write a program in any language in which to get the BUILD_USER_ID environment BUILD_USER_ID , verify it with the list of hosts and continue or stop working. Match lists of hosts and users are stored in the git repository with public access for reading, but writing (push) is only for favorites.

   Restriction - the ability to control access only from the Jenkins task code. Actual user access to a specific SSH host will in no way be related to access via Jenkins. But it can be an advantage.

3. Without Jenkins at all

   If users are competent enough, then Jenkins is not needed to run scripts at all. A simple scheme with access control by keys is enough, to wrap scripts in ansible, or at least in local shell scripts, which will then be launched using ./name.sh . If you choose ansible and want to save users from even writing long lines, you can wrap typical tasks in Make or python-invoke. I do something like this:

    @task def deploy(ctx, *hostnames): # в Ansible хосты перечисляются через ':' ansible_limit = ':'.join(hostnames) ctx.run('ansible-playbook deploy.yml -i hosts -l {}'.format(ansible_limit))