faas-netes
faas-netes copied to clipboard
openfaas
Feature: support Service Account Volume Project with expiry and audience fields
Service Account Volume Projection
This allows you to set things like the token expiry (expirationSeconds) and audience on a mounted service account token. These parameters can then be used to authenticate access to other "Apps" within the same cluster. For example, see here: https://learnk8s.io/microservices-authentication-kubernetes
Expected Behaviour
Ability to define and set audience and expirationSeconds on a Service Account token mounted with Volume Projection. Possible this could be done with further annotations or perhaps using a Profile resource.
Current Behaviour
Currently it appears the token is mounted with Volume Projection and the expirationSeconds is set, but there seems to be no way to change the duration of expiration settings not any way to define and add an audience property on the token.
Are you a GitHub Sponsor (Yes/No?)
Yes, Ratehub.ca. Contact Chris Richard (at Ratehub). Check at: https://github.com/sponsors/openfaas
- [/ ] Yes
- [ ] No
List All Possible Solutions and Workarounds
No real workarounds if we continue to use OpenFaas.
Which Solution Do You Recommend?
I think attaching these extra settings to a Profile resource may be the best approach. It would allow us to set the expiry and audience properties on tokens on sets of Functions. The controller would then have to be updated to apply these properties to the projected volume for the ServiceAccount token on the created Deployment resource.
Context
This approach (https://learnk8s.io/microservices-authentication-kubernetes) can greatly improve security on inter-pod communications by having the Kubernetes TokenReview API validate the identity of a calling pod.
Your Environment
-
OpenFaas version: faasnetes 10.0.21 (with "Pro" license) installed with the helm chart.
-
What version and distriubtion of Kubernetes are you using?
kubectl versionGKE 1.22 (Google Cloud managed kubernetes) DOKS 1.22 (DigitalOcean managed kubernetes)
Hi @jkirkham-ratehub I'm struggling to understand what you're asking for here or where you think Service Account Volume Projections need to be used? And instead of what?
Can you explain 1) what the problem is that you're running into? 2) why you feel you need this change?
Ok, it is pretty simple. To use ServiceAccount tokens for inter-service (inter-pod) authentication, you NEED 2 things on top of the standard bound service account tokens:
- The ability to set the token expiry to a desired number of seconds.
- The ability to set the "audience" property on the token.
Currently, OpenFaas (faas-netes) does appear to set the token expiry, but there appears to be no way to control this. Similarly, there is no way to set the "audience" property on a token.
If we want to treat micro-services implemented as OpenFaas Functions as being the same utility as other micro-services in our kubernetes cluster then this is a requirement/feature-request. Otherwise, we will be unable to do the desired, secure integrations with other services in our cluster so we would have to migrate to another solution.
The simple things are sometimes they hardest to explain to others.
Where do you want these tokens? In functions? Why do your functions have service accounts? Do they talk to the Kubernetes API?
The threat to move to another solution sounds a bit off-brand for RateHub. It sounds like you have a technical solution in mind that you'd really like to use, but the problem isn't being explained well enough. We reviewed your issue with the team and need more clarification.
The usual way to encrypt traffic between Pods is to use a different network driver or a service mesh. Most of our commercial customers use Istio.
We aren't worried about encrypting traffic between pods. We want to authenticate traffic between pods. Yes, we could set up network policies and/or linkerd policies to restrict who can talk to what, but all other (non faas) pods in our cluster are capable of this solution using Project Volume mounts of Service Account tokens. I'm just saying we don't want to treat faas Pods as "other"/lower-class citizens in our cluster. If this is too difficult to understand I can come up with a work-around, maybe using a mutating webhook to achieve the same thing. Thanks anyway.
Hey Alex to elaborate more, basically we want to take the token (service identity) from the projected volume, and send that to another service in http request header and the receiving service will validate it before executing a task on that called endpoint, also checking the audience in the token to make sure service b is in fact is allowed to execute this endpoint on service A , these are usually on services that contain admin type operations in the endpoint and want the additional security check
Simple Example: service B, C, D has aud: 'A' defined on there projection token, service A receives the token validates and checks the aud, yes it is allowed to execute, say service Z sends its token over, but does not have the aud set for service A, service A says no you do not have a token configed to execute this end point.
This would only be done on select secured endpoints. Some openfaas functions access secured endpoints on larger services and we want this additional check, currently we use our auth-service for this but would like to move it to k8s for these checks.
This also allows us to deny any http request that don't have a valid identity token, and just to point out we try to minimise service (faas)-to-service communication, but in some cases we would like to
I've caught up with several members of the openfaas community on this ticket, including a second airing at our community call. It may help if you attend one of our weekly calls to present your case.
https://docs.openfaas.com/community/
If you want us to consider working on this, then we are going to need YAML for a Pod Spec, Service Account and Secret definition. Along with a brief code sample showing how you plan to consume the Kubernetes service account within each function.
We also have to ask (again), why you are attempting to authorise openfaas functions through a Kubernetes service account? If that's what you're doing then Istio (or Istio Ambient Mesh) or Linkerd would provide a much better option than homebrew crypto/auth/n/z.
I also have to ask whether you are invoking functions from one another directly?
We do not recommend any openfaas workload contact another directly, but that it goes via the gateway so that autoscaling, scale from zero and metrics can be managed properly.
Alex
Closing as inactive.
Feel free to raise a feature request in the OpenFaaS Pro discussions forum.
Alex