[FLI-941] Ability to define trusted service account + namespace when using Kubernetes Auth method

[markphelps]

Discussed in #2944

^{Originally posted by tstraley April 3, 2024}
Based on these docs, if a client provides it's service account token and it is validated as being part of the same Kubernetes cluster that Flipt is running in, that client will be authorized and receives a client access token.

It would be great if Flipt could be configured with a list of trusted / allowed service account name + namespace pairs that are verified from the jwt claims, rather than trusting any service account in the cluster. This can be used to provide more refined auth where only the specific clients that we want to connect to the service are allowed.

_FLI-941

[tstraley]

For reference, this includes an example service account JWT payload: https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#serviceaccount-token-volume-projection

The sub subject claim is what AWS EKS uses in their IRSA flow, and might be the cleanest solution for this.

I was trying to see if I could use Flipt's JWT auth method to do this today, but it looks like only the iss and aud claims support validation. Would it be worth writing up a separate issue to discuss the JWT auth mechanism and supporting additional common claims like sub, or possibly even arbitrary claims (eg. I can provide my own claim key-value pairs in configuration)?

[markphelps]

Yeah great idea. I think the ability to validate custom claims makes a lot of sense. A separate issue would be good. It shouldn't be too difficult to support

[markphelps]

@tstraley we just released v1.41.0 that contains support for verifying sub claims! https://docs.flipt.io/configuration/authentication#claim-validation

Will this work for your usecase or would you still prefer we support

a list of trusted / allowed service account name + namespace pairs that are verified from the jwt claims

?

[tstraley]

@tstraley we just released v1.41.0 that contains support for verifying sub claims! https://docs.flipt.io/configuration/authentication#claim-validation

Will this work for your usecase or would you still prefer we support

a list of trusted / allowed service account name + namespace pairs that are verified from the jwt claims

?

@markphelps thanks for this. I think the recent addition is a step in the right direction, but it still doesn't solve our use-cases simply due to the fact that solution only supports a single subject that can be verified.

If we have more than one service in our cluster that should be allowed to access flipt, and they use different service accounts (or are in different namespace) then this solution doesn't work.

I think the most user-friendly solution would still be to have the kubernetes auth method support a list of allowed service accounts; but the workaround of configuring the jwt auth method by using the service account token would be reasonable if we could define a list of claims to validate.

[tstraley]

Having said that, I should let you know this isn't critical for us -- we have changed our auth method to use the bootstrap static token method, so that we can manage the token like a password and pass it into trusted services via k8s secret (which won't exist in untrusted namespaces).

[markphelps]

@tstraley we just released v1.41.0 that contains support for verifying sub claims! https://docs.flipt.io/configuration/authentication#claim-validation
Will this work for your usecase or would you still prefer we support

a list of trusted / allowed service account name + namespace pairs that are verified from the jwt claims

?

@markphelps thanks for this. I think the recent addition is a step in the right direction, but it still doesn't solve our use-cases simply due to the fact that solution only supports a single subject that can be verified.

If we have more than one service in our cluster that should be allowed to access flipt, and they use different service accounts (or are in different namespace) then this solution doesn't work.

I think the most user-friendly solution would still be to have the kubernetes auth method support a list of allowed service accounts; but the workaround of configuring the jwt auth method by using the service account token would be reasonable if we could define a list of claims to validate.

that makes sense @tstraley

from a configuration aspect, how do you envision that looking?

maybe something like:

authentication:
  methods:
    kubernetes:
      enabled: true
      allowed_service_accounts:
        my-namespace:
          - my-service
        my-other-namespace:
          - my-other-service

? I based this a bit off what we do for allowed_teams for the GitHub auth for consistency sake