{"id":3798,"date":"2019-07-06T15:39:49","date_gmt":"2019-07-06T20:39:49","guid":{"rendered":"https:\/\/dev.iachieved.it\/iachievedit\/?p=3798"},"modified":"2019-07-06T15:39:49","modified_gmt":"2019-07-06T20:39:49","slug":"auditing-shared-account-usage","status":"publish","type":"post","link":"https:\/\/dev.iachieved.it\/iachievedit\/auditing-shared-account-usage\/","title":{"rendered":"Auditing Shared Account Usage"},"content":{"rendered":"

Occasionally you find yourself in a situation where utilizing a shared account cannot be avoided. One such scenario is managing the deployment of NodeJS applications with Shipit<\/a> and PM2<\/a>. Here’s how the scenario typically works:<\/p>\n

Alice, Bob, and Carol are three developers working on NodeJS applications that need to be deployed to their staging server. They’ve decided on the use of PM2 as their process manager, and ShipIt as their deployment tool. Their shipitfile.js<\/code> file contains a block for the staging server, and it looks something like:<\/p>\n

[code lang=text]
\nstaging: {
\n servers: [
\n {
\n host: 'apps.staging.iachieved.it',
\n user: 'deployer',
\n },
\n ],
\n environment: 'staging',
\n branch: 'develop',
\n },
\n[\/code]<\/p>\n

As we can see the deployer<\/code> user will be used to deploy our application, and by extension, will be the user that pm2<\/code> runs the application under. Alice, Bob, and Carol all have their SSH keys put in \/home\/deployer\/.ssh\/authorized_keys<\/code> so they can deploy. Makes sense.<\/p>\n

Unfortunately what this also means is Alice, Bob, or Carol can ssh<\/code> to the staging server as the deployer<\/code> user. Even though deployer<\/code> is an unprivileged user, we really don’t want that. Moreover, by default, we can’t trace who deployed, or if someone is misusing the deployer<\/code> user. Let’s take a look at how we can address this.<\/p>\n

Creating a Deployment Group<\/h2>\n

The first thing we want to do is to create a security group for those that are authorized to perform deployments. I’ll be using an Active Directory security group in this example, but a standard Unix group would work as well. We can use getent<\/code> to see the members of the group. getent<\/code> will come in handy to help determine whether someone attempting to deploy is authorized.<\/p>\n

[code lang=text]
\n# getent group "application deployment@iachieved.it"
\napplication deployment@iachieved.it:*:1068601118:alice@iachieved.it,bob@iachieved.it
\n[\/code]<\/p>\n

SSH authorized_keys command<\/h2>\n

Until I started researching this problem of auditing and restricting shared account usage I was unaware of the command<\/code> option in the SSH authorized_keys<\/code> file. One learns something new every day. What the command<\/code> option provides for is executing a command immediately upon SSHing via a given key. Consider that we put the following entry in the deployer<\/code> user ~\/.ssh\/authorized_keys<\/code> file:<\/p>\n

[code lang=text]
\nssh-rsa AAAA…sCBR alice
\n[\/code]<\/p>\n

and this is Alice’s public key. We would expect that Alice would be able to ssh deployer@apps.iachieved.it<\/code> and get a shell. But what if we wanted to intercept this SSH and run a script instead? Let’s try it out:<\/p>\n

deployer@apps.iachieved.it:~\/.ssh\/authorized_keys<\/code>:<\/p>\n

[code lang=text]
\ncommand="\/usr\/bin\/logger -p auth.INFO Not permitted" ssh-rsa AAAA…sCBR alice
\n[\/code]<\/p>\n

When Alice tries to ssh as the deployer<\/code> user, we get an entry in auth.log<\/code>:<\/p>\n

[code lang=text]
\nJul 5 22:30:58 apps deployer: Not permitted
\n[\/code]<\/p>\n

and Alice sees Connection to apps closed.<\/code>.<\/p>\n

Well that’s no good! We do<\/em> want Alice to be able to use the deployer<\/code> account to deploy code.<\/p>\n

A Wrapper Script<\/h2>\n

First, we want Alice to be able to deploy code with the deployer<\/code> user, but we also want to:<\/p>\n