I have a custom WSGI-based Python passenger app. This app needs to access a protected API for which a password is needed. What is the best way to make sure that the password is sourced by my passenger app but not readable by PUN users?
Storing the password in an environment file to be read by python does not seem to work because PUNs are executed by common users which will have to have reading access to the environment file.
I have also tried to add the passwd as a custom environment variable in /etc/ood/config/nginx_stage.yml as a pun_custom_env and make that file only readable by root but with no success.
Also using the scheme /etc/ood/config/apps/$APP/env to define new variables does not seem to work as my app is unaware of anything defined there.
Setting a custom variable in /etc/ood/config/nginx_stage.yml under pun_custom_env works, however this does not prevent a user from displaying in their own custom apps all the environment variables which will leak the credentials. Is there a way to make an environment variable only available to one particular app? Maybe using /etc/ood/config/apps/$APP/env? So far though any variables defined there are invisible to my app.
Yea, I’m not sure if you can do this. Here’s the thing - when the PUN boots up, it runs in the users’ context, with their UID/GID(s). So if you set an environment variable in /etc/ood/config/apps/$APP/env a sophisticated user may be able to read those configs, because that file needs to be readable by that user (again because the PUN is running as them).
So there’s that - you can obfuscate where this comes from, but that’s about it. A sophisticated/motivated user can find this.
As I see it you have 2 approaches - use a shared credential as you indicate in /etc/ood/config/apps/$APP/env. Your app will need to read this file, it doesn’t just happen, our apps use the library dotenv to read this (a quick google search shows this package is available for python).
An alternative route is to have credentials for every single user. This way, no credentials leak because any credentials the user has access to are their credentials and so if they were malicious or careless you could simply disable that user without locking out others.
This is how we setup kubernetes access. Folks have their own credentials in ~/.kube/config. There are docs for the same on how we use the pun_root_pre_hook to generate OIDC kubernetes credentials for each user. You may be able to use the same facility.