Reliably Deploying Rails Applications: Hassle free provisioning, reliable deployment (2014)

7.1 - Users

Overview

In this chapter we’ll cover automating adding users and public keys to the remote server.

We’ll be looking at the following cookbooks:

· users

· sudo

Which are setup and applied in roles/server.json

These are third party cookbooks which deal with the standard requirements of user management, password generation and controlling who has access to sudo.

Users

The users cookbook contains a recipe called sysadmins. This deals with creating users in a group called sysadmins.

Unlike other elements of the system, user configuration is done outside of the node and role definition files. Instead the configuration is stored in what are called data bags.

Recall in our original chef solo project we had a folder called data_bags. Data bags are generally used when a cookbook requires larger chunks of data to be provided to it.

If you look in the data_bags/users directory there’s a file called deploy.json.example which looks like this:

1 {

2 "id": "deploy",

3 // generate this with: openssl passwd -1 "plaintextpassword"

4 "password": "",

5 // the below should contain a list of ssh public keys which should

6 // be able to login as deploy

7 "ssh_keys": [

8 ],

9 "groups": [ "sysadmin"],

10 "shell": "\/bin\/bash"

11 }

ID is the username of the user and should match the name of the file.

The password for the user is not the users plain text password (you don’t want this stored in plain text anywhere outside of a password manager). Instead it is a hash of the password which can be generated locally using:

1 openssl passwd -1 "plaintextpassword"

which will generate an output like:

1 $1$wNIBg4QQ$/b46CoUAqP8EcmeF9.QaQ/

Which is what should be entered for the password value in your data bag.

The ssh_keys key should contain an array of public ssh keys which can be used to login as that user. You can usually access your own local public key with:

1 cat ~/.ssh/id_rsa.pub

The output of which should then be copied into the array as a string (e.g. surrounded by quotes).

groups should be an array of strings, with each string referring to a single group that the user should be a member of.

Finally shell is a string which should be the path to the users default shell. This can be used, for example, for switching from the default bash shell to something like Zsh or Fish.

The users recipe will go through the .json files in data_bags/users and create each of the users defined.

The users cookbook allows many other attributes to be set and we’ve only scratched the surface of what it can do here. The documentation in the cookbooks README is excellent so I strongly recommend spending some time getting familiar with it.

Sudo

In addition to adding the users and setting up public keys, we’ll setup who can use sudo and how. The following section in our server.json role governs the use of sudo:

1 "authorization": {

2 "sudo": {

3 // everyone in the group sysadmin gets sudo rights

4 "groups": ["sysadmin"],

5 // the deploy user specifically gets sudo rights

6 "users": ["deploy"],

7 // whether a user with sudo rights has to enter their

8 // password when using sudo

9 "passwordless": "false"

10 }

The comments should be fairly self explanatory however a quick note on passwordless sudo. This can be very convenient however, if due to a vulnerability in your app, an attacker is able to execute shell commands as your apps user and this user has passwordless sudo enabled, they would be able to execute commands as root, significantly increasing the damage they could do.

If you wish to have an account with passwordless sudo enabled for convenience, I would suggest having a separate devops user which you login as rather than enabling it for your app user.

Next we’ll look at some basic steps to lock down the server against unauthorised access.