Reading app secrets locally

[can3p]

Hi everyone!

I have a question regarding secrets management on fly. I’ve read the docs and search the forum and it looks like flyctl does not allow reading secret values partially by design and partially to improve the security.

I have two questions there:

• I’m not really sure I understand the security argument of it. For example, it’s still possible to print the secrets by running flyctl ssh console -C 'env'. The only problem there is that fly vars like FLY_APP_NAME are mixed with the secrets explicitly set by users. That’s not a problem at all in case someone wants to steal the secrets, other wise it’s really simple to join this with the output of flyctl secret list to get the vars. On the other hand the fact that secrets are not easy to read forces developers to create local .env files with the same secrets which represents a security issue on it’s own joined by the fact that sometimes it’s really handy to be able to read the secrets anyway e.g. in case of troubleshooting. From my understanding there might be some part missing in the solution that would make the secrets management easier like aws secrets manager or similar. What’s the fly stance on this?

• The second question is related. It’s often really useful to write one-off scripts to perform certain tasks - update the data, send a one-off email etc. There is little point in deploying them on fly since they’re not used by the running app. If using the secrets from fly locally is discouraged, what would be your recommendation on how to perform these tasks?

Thanks in advance for the answers!

[can3p]

Ugly script to prove the concept

#!/usr/bin/env perl

my $vars=`flyctl secrets list | grep -v DIGEST  | awk '{ print \$1 }'`;
my $output=`flyctl ssh console -C 'env' 2>/dev/null`;

my %lookup = map { $_ => 1 } split /\n/, $vars;


for (split /\n/, $output) {
  my ($varname) = split /=/;

  if ($lookup{$varname}) {
    print "$_\n";
  }
}

[lubien]

@can3p

What’s the fly stance on this?

Thomas explained it better here:

Why is `fly secrets list` not showing the values?

Our API doesn’t have access to the contents of secrets. When you set a secret through the API, we seal it in a software HSM, to which our API server has no access (we currently store an authenticator tag of the secret so you can match them up between apps, but I’m dubious about the value of this feature and lobbying to get rid of it). You can, of course, recover secrets by SSH’ing into an app, or, for that matter, deploying a new version of your code that simply logs the secret in plaintext; at…

@can3p

If using the secrets from fly locally is discouraged, what would be your recommendation on how to perform these tasks?

it’s fine making those scripts, really! We aim to make it more difficult for anyone get those secrets but the right people (read: ACL) in your organization will still be able to use them.

[can3p]

Thanks for the reply! Do I understand it correctly that not putting this feature in the flyctl like flyctl secrets get is just to have this line of defense that that someone should at least know how to write a script I posted or even just run the other two commands?

I understand the security concern, what I’m confused about is that it’s already possible and not having a command to get secrets does not add much from the security point of view.