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

Expose username and group from the appropriate headers #110

Closed
braghettos opened this issue May 14, 2024 · 9 comments
Closed

Expose username and group from the appropriate headers #110

braghettos opened this issue May 14, 2024 · 9 comments

Comments

@braghettos
Copy link

braghettos commented May 14, 2024

Hi everyone! We're implementing an aggregation layer leveraging the apiserver package. In our use case we need to retrieve the headers in order to understand who's the user making the request.

We were looking at the documentation: https://kubernetes.io/docs/tasks/extend-kubernetes/configure-aggregation-layer/#extension-apiserver-authenticates-the-request - in particular the following paragraph:

Check that the TLS connection was authenticated using a client certificate which:

  • Was signed by the CA whose certificate matches the retrieved CA certificate.
  • Has a CN in the list of allowed CNs, unless the list is blank, in which case all CNs are allowed.
  • Extract the username and group from the appropriate headers

But it seems that the apiserver package is not exposing these headers. Could anyone help me pointing out if there's a way to retrieve these headers after the authn/authz phases?

Thanks for any help!

@braghettos
Copy link
Author

To date, we put all the custom logic here =>
https://github.com/kubernetes/apiserver/blob/master/pkg/registry/generic/registry/store.go#L170 that is, after the CR has been taken from the store (etcd). The ideal would be to have the object here in this method
https://github.com/kubernetes/apiserver/blob/master/pkg/authentication/user/user.go#L20

@fedebongio
Copy link

/cc @deads2k @enj @liggitt

I'll let the experts comment on this one. I have the feeling that there is a reason why such functionality is not already implemented, but I'm not a security expert.

@enj
Copy link
Member

enj commented May 15, 2024

All of this stuff is done automatically for you if you wire your server correctly, for example DelegatingAuthenticationOptions takes care of authentication.

func (s *DelegatingAuthenticationOptions) ApplyTo(authenticationInfo *server.AuthenticationInfo, servingInfo *server.SecureServingInfo, openAPIConfig *openapicommon.Config) error {

request.UserFrom can be used in later layers to get the user.Info:

func UserFrom(ctx context.Context) (user.Info, bool) {

@enj
Copy link
Member

enj commented May 15, 2024

Use this code as an example for wiring up an aggregated API server correctly.

@lucasepe
Copy link

Hi @enj thank you very much for your quick response!

What we would like to do is to access the user.Info struct from this Decorator => apiserver/pkg/registry/generic/registry/store.go#L170.

Decorator that is used, for instance, here => apiserver/pkg/registry/generic/registry/store.go#L812.

Since this Decorator des not expose the Context, we can’t do the UserFrom(ctx context.Context) call.

Taking as reference the sample-apiserver, exists a way to access to the user.Info who is asking for the resource from within the Decorator?

All the best,
Luca

@enj
Copy link
Member

enj commented May 15, 2024

@lucasepe I am not sure that I would recommend that you change the resource based on the user, but you can do that via:

  1. Wrap the GenericConfig.RESTOptionsGetter of your server
  2. Have it return a RESTOptions that further wraps the existing StorageDecorator
  3. Have the new StorageDecorator wrap the storage.Interface
  4. Have your new storage.Interface methods such as Get use the request context to perform whatever mutation you want on the returned resource

@lucasepe
Copy link

Thank you very much @enj ! It works!

All the best,
Luca

@enj
Copy link
Member

enj commented May 16, 2024

/close

@k8s-ci-robot
Copy link
Contributor

@enj: Closing this issue.

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants