5 ms·

Instrumenting Next.js with runtime secret injection

20 points by nimishk 1y ago

latchkey 1y ago
"https://api.phase.dev https://api.phase.dev" 100% uptime, I'm sure.
- cowthulhu 1y ago
  Are you making the argument that they should have a default API route? I don't think that's very common.
  - latchkey 1y ago
    I'm making the argument that I wouldn't rely on an API endpoint to serve up the secrets that enable my application to work. Imagine a network outage or endpoint failure when the app just happens to be redeployed.
    - duncanfwalker 1y ago
      I think it depends on the API - we do this with AWS Secret Managers. I haven't seen it fail but if did it would only effect new instances coming into service so I think we'd have to be pretty unlucky for it to have a noticeable impact.
      - latchkey 1y ago
        This wasn’t an AWS Secrets Manager example, and yes, there’s a guy named Murphy who wrote a law about this kind of thing.
        duncanfwalker 1y ago
        It's true that anything that can go wrong will go wrong but I wouldn't use that as a maxim to direct designs - risk is one trade-off and it's significance varies.
        latchkey 1y ago
        Nah, we’ve been doing this long enough that handling network failure is just the default assumption now, we should be designing and coding for it, by default.
    - karmakaze 1y ago
      That's a whole category of software that makes large systems work: etcd, Zookeeper, HashiCorp Vault, etc.
      - latchkey 1y ago
        Yes! All built with redundancy in mind. https://etcd.io/docs/v3.3/op-guide/ https://etcd.io/docs/v3.3/op-guide/ https://zookeeper.apache.org/doc/r3.9.3/zookeeperStarted.html#sc_RunningReplicatedZooKeeper https://zookeeper.apache.org/doc/r3.9.3/zookeeperStarted.htm... https://developer.hashicorp.com/vault/tutorials/day-one-raft https://developer.hashicorp.com/vault/tutorials/day-one-raft
    - jitl 1y ago
      Where should secrets come from then? Burn them into the deployable artifact??? Place them on the host filesystem in perpetuity???
ashwinsundar 1y ago
Looks like the Next.js gish-gallop machine is firing on all cylinders, augmented by generative AI. .env files are problematic because they often end up in version control or left lying on local disks unencrypted, increasing the risk of a secret leak. They're nearly impossible to manage securely at scale, are difficult to distribute across a team, and offer no access control or security. Sure, if your developers live in a bubble and don't know any better. Otherwise, .env files are fantastic because they are dead simple. Keeping them out of VCS is simple. echo ".env" >> .gitignore. Need to share a secret value? Use any number of secure communications systems your company has in place. Or generate your own from the system that is issuing secrets. It's not the 1950s, when sharing a secret was considered a national security endeavor. This doesn't need to be rocket science. You can communicate what's supposed to go in the .env file with a .env.template file, with a list of env variables set equal to an empty string. I'm glad they at least share the nightmare that is client-side environment variables. Prepare to waste days/weeks of your life sifting through unresolved issues in Next.js repo on GitHub, only to discover that you have to re-architect vast swaths of an application just so a secret (of any kind) is never required on the client. This is incredibly challenging and frustrating to deal with, especially when on a deadline and you're 95% done with a working solution. In typical Next.js fashion, the official documentation for instrumentation.ts is complete dog crap. It's deceptively short, making the naive developer think it's simple to configure. In reality, you should first read through the 50 open and 71 closed GitHub issues related just to instrumentation (https://github.com/vercel/next.js/issues?q=is%3Aissue%20state%3Aopen%20instrumentation https://github.com/vercel/next.js/issues?q=is%3Aissue%20stat...), and make sure you understand all the undocumented ways in which instrumentation.js will destroy any semblance of productivity or enjoyment of programming. I'd highly recommend staying away from the dumpster fire that is Next.js. It's too bad it's like the top skill asked for by employers these days, who seem to have no idea what they're signing up for.
- politelemon 1y ago
  TIL https://en.m.wikipedia.org/wiki/Gish_gallop https://en.m.wikipedia.org/wiki/Gish_gallop
- jitl 1y ago
  > just so a secret (of any kind) is never required on the client This is how web clients usually work though not NextJS special at all. You have a HTTP only cookie for authentication and proxy requests through your backend to authorize client to perform actions that depend on secrets. I’m not a NextJS proponent and have experienced frustrations running into its limitations but I think in this case it’s unfair to malign it. If anything NextJS makes this easier, you just move your function call that uses a secret to a “use server” file and add an authorization check but your client code doesn’t need to change you keep importing it and calling it like a regular async function.
theozero 1y ago
Next.js env var tooling could definitely use some improvement, and pulling from a secure external vault makes sense, but I think there's more to it. Have you seen http://varlock.dev/integrations/nextjs http://varlock.dev/integrations/nextjs
loliver666 1y ago
I'm tired of all the Next.js slander. It works great.

20 points by nimishk 1y ago

latchkey 1y ago

"https://api.phase.dev https://api.phase.dev" 100% uptime, I'm sure.

cowthulhu 1y ago
Are you making the argument that they should have a default API route? I don't think that's very common.
- latchkey 1y ago
  I'm making the argument that I wouldn't rely on an API endpoint to serve up the secrets that enable my application to work. Imagine a network outage or endpoint failure when the app just happens to be redeployed.
  - duncanfwalker 1y ago
    I think it depends on the API - we do this with AWS Secret Managers. I haven't seen it fail but if did it would only effect new instances coming into service so I think we'd have to be pretty unlucky for it to have a noticeable impact.
    - latchkey 1y ago
      This wasn’t an AWS Secrets Manager example, and yes, there’s a guy named Murphy who wrote a law about this kind of thing.
      - duncanfwalker 1y ago
        It's true that anything that can go wrong will go wrong but I wouldn't use that as a maxim to direct designs - risk is one trade-off and it's significance varies.
        latchkey 1y ago
        Nah, we’ve been doing this long enough that handling network failure is just the default assumption now, we should be designing and coding for it, by default.
  - karmakaze 1y ago
    That's a whole category of software that makes large systems work: etcd, Zookeeper, HashiCorp Vault, etc.
    - latchkey 1y ago
      Yes! All built with redundancy in mind. https://etcd.io/docs/v3.3/op-guide/ https://etcd.io/docs/v3.3/op-guide/ https://zookeeper.apache.org/doc/r3.9.3/zookeeperStarted.html#sc_RunningReplicatedZooKeeper https://zookeeper.apache.org/doc/r3.9.3/zookeeperStarted.htm... https://developer.hashicorp.com/vault/tutorials/day-one-raft https://developer.hashicorp.com/vault/tutorials/day-one-raft
  - jitl 1y ago
    Where should secrets come from then? Burn them into the deployable artifact??? Place them on the host filesystem in perpetuity???

ashwinsundar 1y ago

Looks like the Next.js gish-gallop machine is firing on all cylinders, augmented by generative AI. .env files are problematic because they often end up in version control or left lying on local disks unencrypted, increasing the risk of a secret leak. They're nearly impossible to manage securely at scale, are difficult to distribute across a team, and offer no access control or security. Sure, if your developers live in a bubble and don't know any better. Otherwise, .env files are fantastic because they are dead simple. Keeping them out of VCS is simple. echo ".env" >> .gitignore. Need to share a secret value? Use any number of secure communications systems your company has in place. Or generate your own from the system that is issuing secrets. It's not the 1950s, when sharing a secret was considered a national security endeavor. This doesn't need to be rocket science. You can communicate what's supposed to go in the .env file with a .env.template file, with a list of env variables set equal to an empty string. I'm glad they at least share the nightmare that is client-side environment variables. Prepare to waste days/weeks of your life sifting through unresolved issues in Next.js repo on GitHub, only to discover that you have to re-architect vast swaths of an application just so a secret (of any kind) is never required on the client. This is incredibly challenging and frustrating to deal with, especially when on a deadline and you're 95% done with a working solution. In typical Next.js fashion, the official documentation for instrumentation.ts is complete dog crap. It's deceptively short, making the naive developer think it's simple to configure. In reality, you should first read through the 50 open and 71 closed GitHub issues related just to instrumentation (https://github.com/vercel/next.js/issues?q=is%3Aissue%20state%3Aopen%20instrumentation https://github.com/vercel/next.js/issues?q=is%3Aissue%20stat...), and make sure you understand all the undocumented ways in which instrumentation.js will destroy any semblance of productivity or enjoyment of programming. I'd highly recommend staying away from the dumpster fire that is Next.js. It's too bad it's like the top skill asked for by employers these days, who seem to have no idea what they're signing up for.

politelemon 1y ago
TIL https://en.m.wikipedia.org/wiki/Gish_gallop https://en.m.wikipedia.org/wiki/Gish_gallop
jitl 1y ago
> just so a secret (of any kind) is never required on the client This is how web clients usually work though not NextJS special at all. You have a HTTP only cookie for authentication and proxy requests through your backend to authorize client to perform actions that depend on secrets. I’m not a NextJS proponent and have experienced frustrations running into its limitations but I think in this case it’s unfair to malign it. If anything NextJS makes this easier, you just move your function call that uses a secret to a “use server” file and add an authorization check but your client code doesn’t need to change you keep importing it and calling it like a regular async function.

theozero 1y ago

Next.js env var tooling could definitely use some improvement, and pulling from a secure external vault makes sense, but I think there's more to it. Have you seen http://varlock.dev/integrations/nextjs http://varlock.dev/integrations/nextjs

loliver666 1y ago

I'm tired of all the Next.js slander. It works great.