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
- 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.)
- Can environment variables of a started systemd service be read by a user?