Granting infrastructure access to employees¶
This page describes howto grant new employees access to your company infrastructure. It also describes how to remove cancelled employees access from the servers.
Employees names are abbreviated like so:
First name: Marianne Eva
Last name: Musterfrau
This results in the abbreviated name: m.musterfrau
OpenVPN for employees¶
The first thing a additional employee needs is OpenVPN access. To add this, edit the file
plays/utilities/openvpn-server.yml
and add the new "client" to the variable openvpn_clients. To generate the OpenVPN client configuration run:
user@workstation:~/code/git/git.example.com/ansible/playbook-infrastructure-TEMPLATE_VAR_CUSTOMER_LOWER$ ./make utils prod openvpn
This will create a new .zip file on exa-utils-prod-gateway-1.exa.io:/etc/openvpn/vpnexa/clients/archives/m.musterfrau.zip. Download this file using scp and priovide it to the additional employee.
The employee will have to unpack the .zip file and copy it to /etc/openvpn/ or similar, depending on the operating system, on her workstation or mobile device.
The OpenVPN server will try to push a route to access all tinc IPs of the servers through it. This may not work on some devices / operating systems, in which case the pushed resolvers have to be manually set up on the employees device.
Passwords for employees¶
In most all cases (where technically possible) Ansible will provision access to the utility services using a specific password for each employee, which is defined in the password-store:
user@workstation:~/code/git/git.example.com/ansible/playbook-infrastructure-TEMPLATE_VAR_CUSTOMER_LOWER$ pass | grep human
├── humans_mmusterfrau_pass
├── humans_mmustermann_pass
[...]
Please note that the passwords filenames here do not contain dots, as the password-store dynamic inventory will create variables from them.
Using this password, the employee can access the WebUI of the respective utility service.
When adding new passwords, the new employee commonly has to be put into the respective Ansile play file of the utility service, which then has to be executed, to gain access.
SSH access for employees¶
Employees, called "humans" in this repository, can be granted SSH access to specific groups of servers.
A list of employees is kept in the file inventory/group_vars/all.yml under in the variable humans. This variable is made use of in several plays, like the SSH play in plays/baseline/ssh.yml.
Each employee which is granted access will have its own Linux user account on the respective groups of servers. Each employee always gets the same UID and GID on all servers, as specified in plays/baseline/ssh.yml. The ssh play makes use of the variable ssh_users, which can be defined in inventory/group_vars/ or inventory/host_vars/, depending on which servers are to be targeted for a specific group of employees.
Once SSH access is set up for a specific employee she can login to the group of servers using her abbreviated username: ssh m.musterfrau@log.example.com.
(Optional) port knocking with fwknop¶
Depending on the configuration, access to the admin IP as well as the public IP of the utilty gateway servers, which serve the OpenVPN service, can be restricted using port knocking. This has the advantage of a much lower amount of lines of code being directly exposed to the internet (only fwknop instead of OpenVPN and SSH).
Fwknop can be installed on all common devices (Linux, Mac OSX, android, iphones and others). Access can be granted to the own IP address or to other IP addresses which can be specified on the device.
If fwknop is configured on the servers, SSH and OpenVPN can only be used when a fwknop client has allowed the public IP address of the router the workstation or mobile device is using to access the internet.
To add a new employee to the list of allowed fwknop users, simply install fwknop and generate a new configuration. Send the generated secret string to the admin so it can be setup in plays/baseline/fwknop.yml.