I have multiple RESTful web services being deployed through Azure DevOps Release Pipelines to a CentOS VM. Each of these services is managed by systemd and uses environment variables to pass in configuration.

Usually my approach would be to create new users for each service and inject the variables into the environment of the user while the release agent runs on the VM. However, as I don't want to create a new user for each service that I add, I use systemd's EnvironmentFile to inject the configuration - even though some of the systemd core members discourage its use. Some of these values are quite sensitive and thus need to be protected.

Current approach to securing the environment files:

Ensure a nologin user owns the environment file

$ chown username:username /path/to/.service.env

Ensure the file is only readable by its owner.

$ chmod 400 /path/to/.service.env

Make the file immutable.

$ chattr +i /path/to/.service.env

Run systemd service as nologin user and pull in environment file using EnvironmentFile=/path/to/.service.env.


  1. Is there any way to further secure the environment file from being accessed? (I suppose encrypting it with a tool such as GnuPG would not work as systemd couldn't read the file.)
  2. Can environment variables of a started systemd service be read by a user?
  • 2
    (2) only root and nologin can read /proc/$PID/environ of your services
    – basin
    Jan 11 '19 at 21:59
  • Thanks @basin! I totally overlooked that!
    – tobias
    Jan 15 '19 at 14:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.