4 ms·

Right. They provide a convenience function that spins up a machine running postgres and adds the right environment variables to any machines you already have ru

Right. They provide a convenience function that spins up a machine running postgres and adds the right environment variables to any machines you already have running. It's "just another machine," but that's not obvious when you're setting it up! Two bits of documentation that are lacking here are: 1. How does this affect billing, especially if you're on the hobby plan? (Answer, as far as I can tell: since it's just another machine, it can be free if and only if you resource it such that it fits in your free "allowances." The defaults are NOT these, however, so you have to be careful if you want to mess around for free). 2. Once the db machine is created...how can I get credentials for it? A connection string is generated upon machine creation but...what if you don't write it down?

verelo 3y ago
Yeah i feel your pain here. Fly has a lot of things that feel like they're hidden features, or at least, undocumented. Like, its trivial to get all the env vars from a machine, but i couldn't find this in the documentation anywhere. Someone else i was working with told me how and now..i know? fly ssh console --command env To be fair, it is mentioned in their docs, i just couldnt find it searching things like "how to find my environment variables".
- arccy 3y ago
  part of it is common sense: fly ssh console == ssh, and then you run env to print the environment variables in your current session (which may not be the exact set of envs your app sees).
- tptacek 3y ago
  There's a whole backstory to this, because we got a big influx of Heroku developers a couple years ago, and Heroku developers all expect to be able to dump all their environment variables, including secrets, from the command line or whatever. We don't do that: our API is like a diode for secrets, and once they're set, they're sealed into a cryptographic vault on separate hardware. It is and has to be the case that you can shell into a machine and get the secrets, which apps all expect to receive in environment variables, but we don't like that you can do that, and wouldn't want to encourage it. Environment variables are hazmat!
  - verelo 3y ago
    Right ok that makes sense. The reason i wanted this was for the reason mentioned earlier in this thread: you spin up a DB but don’t have the credentials. Fortunately i had stored them as an env var and was able to recover them, but otherwise i felt at a loss on how to gain access.
    - tptacek 3y ago
      Right, that's exactly the kind of environment variable we don't want you to be able to easily retrieve. Interestingly, there's a big intersection with Macaroons here. We're replacing Vault (for customer secrets, not for TLS keys or infra secrets) with an internal, Macaroon-integrated secret store called Pet Semetary, and one of the use cases for it is to come up with a high-assurance way to give customers straightforward access to secrets without having to reverse engineer them from their machines. At any rate: this is all a consequence of our security model. A vulnerability in our Rails API server (which is not, like, beyond the frontiers of possibility) would give you enough access to jumble up everyone's secrets, but not to read them. We're happy to take our lumps for how annoying that makes our DX sometimes. :)
      - verelo 3y ago
        How do you want these things stored? And further, is there a way to regain access if someone looses their db credentials in the fly environment?
        tptacek 3y ago
        As you can see from the thread, and from, like, logical deduction, you can recover credentials from a shell on the Fly Machine your app runs on (because, after all, your app needs access to those secrets). But just dumping them from the API implies an API server that has access to the secrets, and that's a hard no from us (it won't be soon, though, because [see upthread]). This is not everybody's optimal DX, and we get that. It's a whole public cloud platform, so there are lots of tradeoffs we have to make.

verelo 3y ago

Yeah i feel your pain here. Fly has a lot of things that feel like they're hidden features, or at least, undocumented. Like, its trivial to get all the env vars from a machine, but i couldn't find this in the documentation anywhere. Someone else i was working with told me how and now..i know? fly ssh console --command env To be fair, it is mentioned in their docs, i just couldnt find it searching things like "how to find my environment variables".

arccy 3y ago
part of it is common sense: fly ssh console == ssh, and then you run env to print the environment variables in your current session (which may not be the exact set of envs your app sees).
tptacek 3y ago
There's a whole backstory to this, because we got a big influx of Heroku developers a couple years ago, and Heroku developers all expect to be able to dump all their environment variables, including secrets, from the command line or whatever. We don't do that: our API is like a diode for secrets, and once they're set, they're sealed into a cryptographic vault on separate hardware. It is and has to be the case that you can shell into a machine and get the secrets, which apps all expect to receive in environment variables, but we don't like that you can do that, and wouldn't want to encourage it. Environment variables are hazmat!
- verelo 3y ago
  Right ok that makes sense. The reason i wanted this was for the reason mentioned earlier in this thread: you spin up a DB but don’t have the credentials. Fortunately i had stored them as an env var and was able to recover them, but otherwise i felt at a loss on how to gain access.
  - tptacek 3y ago
    Right, that's exactly the kind of environment variable we don't want you to be able to easily retrieve. Interestingly, there's a big intersection with Macaroons here. We're replacing Vault (for customer secrets, not for TLS keys or infra secrets) with an internal, Macaroon-integrated secret store called Pet Semetary, and one of the use cases for it is to come up with a high-assurance way to give customers straightforward access to secrets without having to reverse engineer them from their machines. At any rate: this is all a consequence of our security model. A vulnerability in our Rails API server (which is not, like, beyond the frontiers of possibility) would give you enough access to jumble up everyone's secrets, but not to read them. We're happy to take our lumps for how annoying that makes our DX sometimes. :)
    - verelo 3y ago
      How do you want these things stored? And further, is there a way to regain access if someone looses their db credentials in the fly environment?
      - tptacek 3y ago
        As you can see from the thread, and from, like, logical deduction, you can recover credentials from a shell on the Fly Machine your app runs on (because, after all, your app needs access to those secrets). But just dumping them from the API implies an API server that has access to the secrets, and that's a hard no from us (it won't be soon, though, because [see upthread]). This is not everybody's optimal DX, and we get that. It's a whole public cloud platform, so there are lots of tradeoffs we have to make.