Kubernetes "trick": Calculate client secret digest "on the fly" (e.g. PBKDF2)

[flypenguin]

(second attempt, sind a reload killed the first ... 🙄)

Situation

• you have a kubernetes secret which contains the OIDC client id for Authelia and the client
• you want to reference the secret from both (Authelia and client) to make things easy for you
• Authelia will soon drop plaintext support for client secrets, so you now need to compute a digest before/during deployment
• You don't want to have any additional tools / jobs / etc. involved.

Solution

It took me a while to come up with it, but it's fairly obvious in hindsight: InitContainers and Authelia command line functions.

Code example

A working example is in my playground repo, and the relevant snippets are shown below:

(I think of creating a PR with this next week, because I really think this should "just work").

Also ping @james-d-elliott @Crowley723 That should also solve any requirements of the running server having access to plaintext secrets, right? :)

# helm-values-authelia.yaml
# shortened for brevity, only the relevant parts are shown
---
pod:
  extraVolumes:
    - name: pre-processed-config-values
      emptyDir: {}

  extraVolumeMounts:
    - name: pre-processed-config-values
      mountPath: /ppc

  initContainers:
    - name: pbkdf2-hasher
      image: ghcr.io/authelia/authelia
      command:
        - sh
        - -c
        - |
          set -euo pipefail
          CS=/ppc/client-secrets
          mkdir $CS
          cd $CS
          echo "Password SHA256: $(echo "$CLIENT_SECRET" | sha256sum)"
          authelia crypto hash generate --password "$CLIENT_SECRET" | sed -E "s/^([^ ]+ )?//" > my-client
          authelia crypto hash validate --password "$CLIENT_SECRET" -- "$(cat my-client)"
          echo "Validation successful."
      env:
        - name: CLIENT_SECRET
          valueFrom:
            secretKeyRef:
              name: authelia-client-secret-xyz
              key: client_secret
      volumeMounts:
        - name: pre-processed-config-values
          mountPath: /ppc

configMap:
  identity_providers:
    oidc:
      clients:
        - client_name: My Client
          client_id: my-client
          client_secret:
            path: /ppc/client-secrets/my-client
          redirect_uris:
            - https://whatever-you-do.please/callback

secret:
  additionalSecrets:
    authelia-client-secret-xyz:
      path: ""
      items:
        - key: client_secret

[james-d-elliott]

Also ping @james-d-elliott @Crowley723 That should also solve any requirements of the running server having access to plaintext secrets, right? :)

I understand what you're trying to do, but this is only marginally better I believe, any party that gains access to the namespace authelia is in, or authelia itself, will have a significant chance to also have access to the plaintext secrets. The secrets should be hashed prior to providing them to Authelia, and only be accessible to the client itself which should exist within a separate security context to authelia, and separate to other clients.

The reason hashing is used and we suggest 80-100 character secrets is that the entropy of a hashed secret of that length is very unlikely to to be breakable by technology in the near future. This will always be the strict stance we take in regards to how passwords are provided to Authelia. This action should be done once if you're following best practice, it's how you store it.

[flypenguin]

The correct process is at the time the secret is generated it is hashed.

That is not a solution, that's a principle, ignoring the reality at hand, as you do with the providers "generating and showing once". That is a really fundamentally flawed example, since someone has to manage the secret itself, and if it's not the provider doing it for you (which you would not see), it is yourself. And then the idea to derive everything from a single source of truth is just the most sane approach. Answering with principles does not help, IMO, because you still have not provided an alternative I can practically do instead without further adding complexity (= prime source of INsecurity) or effort.

There's probably no reasonably likely way a party would have access to the pod without first having access to the namespace itself, the access to the namespace is what gives them access to the pod, and conversely all of the secrets in the init container.

Eh, no. If I "hack" Authelia using an exploit, I have exactly that, which is also the most likely scenario we should discuss. We can also discuss how to secure K8S to prevent outside intrusions, but this would not be the right place and context, since this is an Authelia-centered discussion.

Values in environment variables are highly vulnerable […]

I fully agree. And again: Authelia has no access to the secret, only to the hash. That it is also Authelia actually hashing it is a minor side note and has nothing to do with the actual system, because once entering the "running" state, this secret is gone.

TL;DR – don't give me abstract principles as answers to concrete real-life problems. That is, if you ask me, doing "security" a disservice in the end.

[james-d-elliott]

That's fine, you have a workflow that works for your environment. The display the password or secret once strategy is something we're moving towards as a design, this doesn't mean people wont be able to use alternatives like this, while we don't provide direct support for them the choice is effectively for the user to make. People can take these recommendations or leave them.

Just newer features are going to require this strategy, an example is the Dynamic Client Registration Flow; which incidentally will be another solution to this problem provided you move to the in-SQL OpenID Connect 1.0 configuration. Same will be the case for the optional admin interface.

The only other recommendation I can make is to have your tooling update and add secrets to Authlia in your repo. All of this can be managed out of band instead of directly in the k8s lifecycle. If there's tooling that's unavailable that makes this particular element easier then realistically that's the element that our team should spend time on (as well as DCRP).

Edit: Like when you brought up the idea to include template functions (that would leave all client secrets in plain text on disk in 3 separate locations, making it a clear out of scope solution), while we will not support things like this, we would be more than willing to add functionality intended to make these things easier. The hashing functions themselves are not the issue, hashing at that stage of configuration is. So a method to template a config from plain text secrets but outputting them as hashed secrets is entirely within scope as long as it's not part of normal daemon execution lifecycle.

[flypenguin]

The display the password or secret once strategy is something we're moving towards as a design, […]

I really hope you're not going to make automated setup impossible by enforcing someone to actually view a web page. 😬

Dynamic Client Registration Flow; which incidentally will be another solution to this problem […]

Only if the clients support it. And I feel it's not going to be as simple as it sounds ... security never is ;)

So a method to template a config from plain text secrets but outputting them as hashed secrets is entirely within scope as long as it's not part of normal daemon execution lifecycle.

That is something I can wholeheartedly embrace :))

[flypenguin]

btw what is "DCRP"? the google results were ... interesting

[james-d-elliott]

btw what is "DCRP"? the google results were ... interesting

DCRP is Dynamic Client Registration Protocol.

I really hope you're not going to make automated setup impossible by enforcing someone to actually view a web page.

As I said, entirely optional. Certain dynamic configuration features will require certain configurations like in-SQL, DCRP cannot be supported without it in any reasonable way. It is part of our approach to security; we are very deliberate in most cases.

Only if the clients support it. And I feel it's not going to be as simple as it sounds ... security never is ;)

DCRP is entirely a programmatic way of dealing with client registration. The client doesn't have to support it. Whatever provisions its credentials does (be it the client itself or a third party).