PRECIOUS DISK IMAGE PASSWORDS PASSWORD
You could maybe pass a password directly in a command if you were running inside a secure container with sandboxing around everything. So, any CLI command worth its salt should not accept passwords directly.
There is no way for the caller of a command to choose to hide the command line from being world readable. In case it isn’t already abundantly clear, this is very unsafe. Use the keyctl command or keyctl system calls. Or you can have a keyring that is inherited across all processes in a user’s session. The Linux keyring offers several scopes for storing keys safely in memory that will never be swapped to disk.Ī process or even a single thread can have its own keyring, There is an keyring facility in the Linux kernel. Often you need to run a secrets manager server and hit an API.Īnd even with a secrets manager, you may still need Bash to shuttle the secret into your target application.įor this post I’m focused on more lightweight solutions. Secrets managers can be great because they can make it easier to get secrets closer to where they are used.įor example, a Docker container can call out to a secrets manager for its secrets.īut, a secrets manager is an extra dependency. The downside is that it appears unsafe, because $STEP_CA_PASSWORD is still getting substituted into something that certainly looks like it’s a command. So, if you are able to otherwise secure your environment variables, this approach is safe. We are saved by the fact that echo is a builtin, and a process will never be created. Local (unexported) shell variables are also easy to leak into ps output:.They might get dumped to STDOUT or logged to a debug logfile. Exported environment variables will get passed to every new process, and then who knows what will happen to them.In systemd, environment variables in unit files are available to users via the dbus interface (see the recent introduction of LoadCredential= for an alternative that uses credential files).In Docker, anyone with access to the Docker daemon can use docker inspect to see all of the environment variables for any running container.Avoid leaking the secret in the command string eg.You can also use files to pass secrets into Docker containers with mounted volumes.Ī few notes about storing and retrieving file secrets: Give each secret a file! Any program that accepts secrets should be able to accept them by passing a filename or by redirecting a file into STDIN. What’s not to love about a file? It’s got an owner. Other than that, there’s not too much to worry about with pipes. The $(< /dev/stdin) leak shown above uses a neat Bash substitution to make an otherwise secure pipe insecure. Because a pipe only has two ends, right? Imagine yourself whispering a secret into one end of a pipe, and a friend putting their ear up to the other. Piped SecretsĪs the sanitized example shows, a pipeline is generally an excellent way to pass secrets around, if the program you’re using will accept a secret via STDIN. Now, no secrets will appear in ps-only filenames. And -H will read the static bearer token from a file ( api_headers).Once jq pushes the secret JSON into the pipe, curl uses the -d flag to pull the secret data directly from the pipe and use it as the HTTPS request body.The -rawfile flag in jq moves the credentials closer to where they are used by delegating the responsibility for reading the certificate data from the files to jq instead of bash.rawfile client_cert $CERT_LOCATION -rawfile client_key $KEY_LOCATION -f. rawfile ca_cert $STEPPATH/certs/root_ca.crt
PRECIOUS DISK IMAGE PASSWORDS HOW TO
We’ll look at some of the risks of these approaches, and how to use each of them as safely as possible.īut first, let’s look at a sanitized version of the above pipeline: We’ll look at three methods for handling secrets on the command line: Using piped data, credential files, and environment variables. To make atonement, I’m writing this post.
arg ca_cert " $(/cmdline, which is globally readable for any process ID.
0 kommentar(er)
