Make it easier to inject PEM-formatted keys into keys[_].private_key

[benweint]

What is the underlying problem you're trying to solve?

There's no easy way to inject a PEM-formatted private key into the keys[_].private_key config file directive described here from an environment variable or file.

PEM-formatted keys look like this:

-----BEGIN PUBLIC KEY-----
<line 1>
<line 2>
<line n>
-----END PUBLIC KEY-----

If you do the naive thing and say this in your config file:

keys:
  my_key:
    private_key: ${MY_PRIVATE_KEY}

... it won't work, because after env var expansion in OPA, you wind up with invalid YAML due to the embedded newlines.

Doing this also doesn't work:

keys:
  my_key:
    private_key: |
      ${MY_PRIVATE_KEY}

... because all lines after the first one wind up missing any leading whitespace, and so again the YAML is busted. Using a flow scalar like this also doesn't work:

keys:
  my_key:
    private_key: "${MY_PRIVATE_KEY}"

... because the embedded newlines wind up being stripped, which the OPA agent's PEM parser doesn't like.

The best option seems to be to preprocess the PEM file to transform literal newlines into the equivalent escape sequence (\n) and then use the flow scalar style, but this is non-obvious and somewhat difficult to debug.

Describe the ideal solution

I'd love to be able to have a private_key_file directive (alternative to private_key) that just points at a file containing the PEM-formatted key.

Describe a "Good Enough" solution

Being able to specify the private key base64-encoded would work too.

Additional Context

Discussed in this Slack thread.

[anderseknert]

Both suggestions seem sensible to me. I think the best practices for injecting secrets have moved further and further away from the use of env vars since we last thought about this, and we should probably revisit this not just for the private_key attribute, but also in-policy secrets like tokens passed to e.g. http.send, and so on. The problem with env vars — especially in a Kubernetes context — is that there's commonly a lot more users allowed to read those (anyone with read access to a pod), than there are users allowed to read secrets. Being able to inject/source a secret from a mounted file in a generic way would be useful, but it would need to come with restrictions, as we don't want any random policy to be able to read any file on disk.

Allowing base64 encoded keys in our config seems like a good way to simplify dealing with what we currently have.

[stale[bot]]

This issue has been automatically marked as inactive because it has not had any activity in the last 30 days.

[anderseknert]

As we concluded in #5391, the right way to do this is almost always to use the --set-file configuration override, which will allow you to point out a file on disk containing the PEM encoded key, rather than having it embedded in your configuration. I made a quick POC using that here earlier today just to verify that it indeed works as intended. With that in place, I think we can close this issue for now. If we later want to investigate other options, let's open another issue at that time.