3

Background

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.

Questions

  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?
  • 1
    (2) only root and nologin can read /proc/$PID/environ of your services – basin Jan 11 at 21:59
  • Thanks @basin! I totally overlooked that! – tobias Jan 15 at 14:43

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Browse other questions tagged or ask your own question.