Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
markphelps opened this issue Apr 4, 2024 Discussed in #2944 · 7 comments
Labels
enhancement Created by Linear-GitHub Sync

Comments

@markphelps
Copy link
Collaborator

markphelps commented Apr 4, 2024

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

@markphelps markphelps added the enhancement Created by Linear-GitHub Sync label Apr 4, 2024
@markphelps markphelps changed the title Ability to define trusted service account + namespace when using Kubernetes Auth method [FLI-941] Ability to define trusted service account + namespace when using Kubernetes Auth method Apr 4, 2024
@tstraley
Copy link

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

@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
Copy link

@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
Copy link

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
Copy link
Collaborator Author

@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

@markphelps
Copy link
Collaborator Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Created by Linear-GitHub Sync
Projects
Status: No status
Development

No branches or pull requests

2 participants