confined role account #1

Supports: xenial trusty
Add to new model


This charm lets members of certain groups sudo to a role account confined by an apparmor profile.

Confined Role Account

This subordinate charm can be used to grant members of a given group read-only access (with optional restrictions on other files as needed) to a specific role account on an instance.

Let's take a look at how you'd deploy our confined-role-account subordinate charm in practice. In our example, we're going to deploy MediaWiki and MySQL, manually add an unprivileged user account on the MediaWiki server, and then configure the confined-role-account subordinate charm so that our unprivileged user can sudo to the www-data user, but with restricted access.

First of all, configure your juju environment and fire up the bootstrap instance.

Then, deploy your charms into the environment:

juju deploy cs:charms/trusty/mediawiki
juju deploy cs:charms/trusty/mysql
juju add-relation mysql mediawiki:db

Now let's manually create our unprivileged user. In a production environment we'd likely have a different means of doing this, such as via ldap.

juju ssh mediawiki/0
$ sudo adduser service-user

Now we can confirm that we can login as the account in question and see what sudo permissions it has by default:

juju ssh mediawiki/0
$ sudo su - service-user
$ sudo -l
Sorry, user service-user may not run sudo on juju-env-machine-1.

Now we can deploy the confined-role-account subordinate charm, set our config options for it, and add a relation to the mediawiki charm:

juju deploy cs:~confined-role-account-charmers/confined-role-account
juju set confined-role-account group=service-user role-account=www-data extra-apparmor-rules="  audit deny /etc/mediawiki/AdminSettings.php r,"
juju add-relation mediawiki confined-role-account

What is this doing? It's saying that anyone in the service-user group can sudo to the www-data role account with the default read-only permissions, but also with /etc/mediawiki/AdminSettings.php not visible to them. This file contains the database password, and in our scenario we want to allow developers access to the mediawiki server as the www-data role account without giving them access to the production database password.

And now let's confirm how things look:

juju ssh mediawiki/0
$ sudo su - service-user
$ sudo -l
Matching Defaults entries for service-user on juju-canonistack-machine-1:
    env_reset, mail_badpass,

User service-user may run the following commands on juju-canonistack-machine-1:
    (www-data) NOPASSWD: /usr/local/sbin/apparmor-wrapper-service-user-www-data \"\"
$ sudo -u www-data /usr/local/sbin/apparmor-wrapper-service-user-www-data
$ echo "this is a test" > ~/this-is-a-test.txt
bash: /var/www/this-is-a-test.txt: Permission denied
$ head /etc/mediawiki/LocalSettings.php
$path = array( $IP, "$IP/includes", "$IP/languages" );
set_include_path( implode( PATH_SEPARATOR, $path ) . PATH_SEPARATOR .
get_include_path() );

require_once( "$IP/includes/DefaultSettings.php" );

# If PHP's memory limit is very low, some operations may fail.
# ini_set( 'memory_limit', '20M' );

if ( $wgCommandLineMode ) {
$ head /etc/mediawiki/AdminSettings.php
head: cannot open '/etc/mediawiki/AdminSettings.php' for reading: Permission denied

We can also see our command history in /var/log/apparmor-wrapper/www-data-history.log:

echo "this is a test" > ~/this-is-a-test.txt
head /etc/mediawiki/LocalSettings.php
head /etc/mediawiki/AdminSettings.php


(string) Extra rules to add to the generated profile.
(string) The group that can transition to the role account.
(string) The role account that members of GROUP can transition to.