Better Secrets Management for NS8 Apps

Development
1

MAjority of the app that we have on NS8 do have their database and othe rpasswords exposed in the source code of the given module, either on the services files, or in the configure module files.

Majority of the application than have requirements for a secret key, or some encryption, we do generate this at runtime or during installation.

While this is a feasible option, it may not be viable for things like database username and password.

Equally, a User might have the need to retrive and make use of the DB credentials for the given application.

is there a plan for a proper secrets manager for the applications implemented into the Nethserver Apps.

My thoughts are.

We can Have Defined Variables within the Apps themselves, Which the USer would be able to have setup from their Dashboard, and retirve of view them from the same.

This could be an integrated solution, or a thrid party module specifically engineered to handle NS8 use cases.

Potential Options Include, but Not Limited to

1 Hashicorp VAult
2) Infisical

Alternatively, we could have them automatically generated and stored in the built-in Redis and provide the users with a Redis explorer App, for retrieval of the said credentials should they be required

Eamples

  1. Redis Commander
  2. Redis Insight

And many others,
Was there a plan by the @dev_team to support something better for handling these many credentials for the different apps we have

1 Like
2

I think we still continue to do like NS7 did., previously secrets were stored in /var/lib/nethserver/secrets and saved in the backup

Now it is the same we store secrets in the environment file that is saved by the backup

We tried to explore a way and generate and store the secret by the podman secret command but we hit some limitations of the podman version of debian

At this point i am not sure we need a central point of secret storage.

1 Like
3

The aim is, to prevent hard codes secrets in the modules, and have them geenrated at runtime, while providing a way/means to query the details by the user, for when they need to use them.

4

You can generate a secret, restrict highly file permission to the user but this secret must be know by containers to identify themselves to the database for example and obviously if you trust a weak container then you have failed your duty of developer

To protect secrets I would like to enumerate so basic statements

One database inside a pod non reachable from outside
One database for one task/container
Rootless container
Only traefik port opened inside the pod
Usage of trusted container from dockerhub

For me the secret is important if it is a master key that protect or encrypt a database, to create a database inside a pod the secret is not so important that you think because the selinux file protects it

Until root is hacked but here it is not the same story

Interesting topic I could be wrong please add your salt

5

I’ve personally dived around secrets handling in the container world and let me tell you, 95% of the cases that you listed is basically pointing a cannon to a fly :smiley:

Using our context, tools you’ve linked address one issue you will likely never see: secret rotation.

And, in the end, the container has the value either in an environment variable or in a directory (you can do it with podman using –secret, for example), so if container is hacked, you still will have access to everything inside the container.

Tools like this are used (and even not at all due to the widespread of built-in solutions in orchestration softwares) when you have to develop something on kubernetes or something like that. Not the case here :person_shrugging:

4 Likes