1. 28
  1.  

  2. 1

    I read the title and, only vaguely knowing what a Terraform provider is, thought briefly that someone was using an infrastructure-as-code framework with Rust as a target. That is, using this complicated declarative system and, instead of using it to make config files on various hosts or whatever, using it to get inside the Rust runtime and set variables in various objects. That would be an amusing inversion, although it would make more sense with Lisp.

    1. 1

      I’m not up to speed on writing gRPC plugins, but it seems that putting a client TLS cert in an environment variable is a gaping security hole. Which I think the OP is alluding to by the way they couched the statement. I’d be curious to know if this is a common practice, and whethet or not it actually presents a security risk being that I imagine a fair amount of secrets traverse plugins.

      1. 4

        A cert should be fine. It only has a public key in it, not the private key. Someone else being able to observe that public key by seeing the env vars in the output of ps is pretty much harmless.

        1. [Comment removed by author]

          1. 1

            What?

            The value set for PLUGIN_CLIENT_CERTIFICATE is a PEM encoded TLS certificate. The private key is not included. The code for this in client.go looks like

            certPEM, keyPEM, err := generateCert()
            ...
            cmd.Env = append(cmd.Env, fmt.Sprintf("%PLUGIN_CLIENT_CERT=%s", certPEM))
            

            The parent process later uses the cert and the private key to authenticate itself to the child process. The child process is expected to reject any requests that aren’t authenticated with the cert given in PLUGIN_CLIENT_CERT. The key for this certificate is held onto by only the parent process.

            1. 2

              Oh okay, I deleted my incorrect comment then. I was going by the explanation in the blogpost. Sorry and thanks for explaining.

              1. 1

                Ah no worries, seriously. ❤️

                PKI is complicated and there are lots of fiddly details that all matter.

                1. 1

                  I was mostly referring to the idea that you need to trust the public key in the environment variable as opposed to the more usual mTLS methods of things like getting the cert signed by the server or adding it to a logged-in user, but this way around makes sense given the pattern of how this is running.

          2. 2

            Given that this is all intended to run on the same machine, or even container, I’m kinda surprised they even bothered with encryption? Like, what would be an actual scenario where this could be exploited?

            1. 3

              Perhaps it was easier to make gRPC do mTLS than to make gRPC run over an AF_UNOX socket or a socketpair()?

              1. 2

                You can actually make it run over a unix socket by sending “unix” not “tcp” and a path to a socket and the code seems to indicate there’s still the certificates. Not sure offhand how mTLS works in that case, because I haven’t tried that path yet.

                1. 1

                  Stupid question, can’t the client turn mTLS off? It looks like there’s a field in a config struct for it.

              2. 1

                What if you’re starting a small netcat program that points to another host? I’m not sure why I would do that, but possibly running in a virtual machine with a different architecture or os.

                1. 1

                  I just don’t remember ever seeing any mentions of running providers non-locally. Like, ever.

            2. [Comment removed by author]