1

I want to implement a zero-deployment strategy for my websever.

My first attempt was to create a specific user (deployer) for that:

# Create user deployer
sudo adduser deployer
# Give the read-write-execute permissions to deployer user for directory /var/www
sudo setfacl -R -m u:deployer:rwx /var/www

With GitLab and some tutorials like this or this, I try to automate the process of deployment.

However, I got stuck because my user deployer needs sudo rights to fire some specific commands.

Now, I wonder can this be an issue? Because I give gitlab the private ssh key to the user deployer, so gitlab can connect to the server.

Because theoretically gitlab can be hacked and therefore my sever as well.

What do you think? Or is the risk so small so I don't need to worry.

Philipp Mochine
  • 113
  • 4

1 Answers1

2

The basics

Yes, if you store access credentials for your server in Gitlab, and Gitlab gets hacked, then your server may get hacked. If the user who is deploying your application needs root access, then you have no choice but to give root access to gitlab (or adjust your application so root access isn't necessary).

User access level

You seem to be specifically concerned about giving Gitlab root access to your server. While that certainly should be avoided if possible, this isn't necessarily the largest concern. After all, if the only thing your server does is host your application, then someone who breaks in as the deployer user already has access to everything of interest. At that point in time making the user root as well doesn't really make it that much more dangerous.

The next step

In an ideal world it wouldn't be a question of "servers" anyway. For instance, if you are running on a dedicated server somewhere then having root get compromised can certainly be a pain. However, if you go a step farther along and are having a VPS or a Kubernetes cluster provisioned from (say) a Docker image, then having any one "server" compromised is less of a hassle. You simply fix up the root issue that caused the compromise and re-deploy on brand new "servers". Obviously breaches are always bad and I'm not trying to say otherwise, but my point is that in well run infrastructure there can be much less concern about "servers", which is a good thing.

Should you put access keys in Gitlab?

Whether or not the risk of having your Gitlab account compromised is something you should worry about is a question that only you can answer. Here's the question you need to ask yourself: "Is the benefit of automating my deployments worth the additional risk of my server being compromised?"

This is effectively a simple risk assessment. Of course to answer that you need to know the likelihood of a compromise, which is harder to answer. To be clear though, Gitlab itself being hacked is (IMO) less likely than security mistakes on your part, i.e.:

  1. Make sure you are using a strong unique password on Gitlab
  2. Enable a secure 2FA account
  3. Make sure you follow best practices regarding storing secrets for CI/CD scripts

Also keep in mind that this is only one of many possible ways a server can be compromised. Making sure that your CI/CD pipeline is well secured is only one priority, and if at the same time you have an open FTP server running on your server, or your application isn't following the basics of application security, then you have bigger fish to fry.

In the end though, only you can decide if this extra automation step is worth the increased risks for you.

Community
  • 1
Conor Mancone
  • 29,899
  • 13
  • 91
  • 96