3 ms·

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. Fortun

by 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.

3 ms·

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. Fortun

by verelo 3y ago

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.