[FLI-941] Ability to define trusted service account + namespace when using Kubernetes Auth method
markphelps opened this issue · comments
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.
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)?
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
@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 we just released v1.41.0 that contains support for verifying
sub
claims! https://docs.flipt.io/configuration/authentication#claim-validationWill 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.
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).
@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 supporta 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
Infisical supports something similar for their k8s auth, they support both Allowed Service Accounts and Allowed Namespaces. https://infisical.com/docs/documentation/platform/identities/kubernetes-auth
Maybe we could do something like:
authentication:
methods:
kubernetes:
enabled: true
allowed_service_accounts:
- my-service
allowed_namespaces:
- production
This would allow for specifying individual service account names, or more broadly at the namespace level
I guess this would be an OR check, like the SA is either in the allowed_service_accounts
list or allowed_namespaces
, but doesn't have to be both