You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As you know today we do gRPC over TLS. In general, I don't know what to expect. @mmlb proposed to remove it until we figure something out and I started doing it until I stopped because I think I want to know more first.
My expectation for TLS is to be able to use it as a way to identify a user and to be able to figure out in the future what that user can do. Almost like a service account for kubernetes.
Right now we are far away from it and as @detiber pointed out here #266 the way we do TLS now is not even flexible enough.
So, what do we want? We can remove TLS for now, demanding it to some other actors like Traefik, NGIX, and similar (it won't be part of sandbox, but we should write tutorials about how to run Tinkerbell gRPC/HTTP API under TLS and cycle back on this topic later... Or something else!
The text was updated successfully, but these errors were encountered:
I think removing it for now makes sense. TLS can then be outsourced to a reverse proxy as you said.
As for authentication and authorization, maybe JSON Web Tokens could be used. They allow for fine grained access control and don't require TLS. I don't know how they integrate with gRPC though. Using JWTs would also give the advantage of decoupling TLS from authentication and authorization.
When it comes to TCP having a layer of encryption is a good practice no
matter what authentication techniques you use.
In Go, we have a good range of libraries available that solve this problem
it is mainly a fact of doing it consciously. For that reason I see a lot of
projects adding TLS, for example, Prometheus did it a few weeks ago.
https://github.com/prometheus/prometheus/blob/5bd7145e554dfb659c14d8527ecdc531f449edc6/docs/configuration/https.md#https-and-authentication
And personally I kind of don't like that much the idea to remove it, half
of myself just want to have it done in a good way (whatever it means :P ),
the other half wants to remove all the code that is not strictly required
to re-write it in a better way... Big struggle!
On Wed, Feb 3, 2021 at 8:12 PM Nicklas Frahm ***@***.***> wrote:
I think removing it for now makes sense. TLS can then be outsourced to a
reverse proxy as you said.
As for authentication and authorization, maybe JSON Web Tokens could be
used. They allow for fine grained access control and don't require TLS. I
don't know how they integrate with gRPC though. Using JWTs would also give
the advantage of decoupling TLS from authentication and authorization.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#432 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMOAO2YVXHW45WO3KEIKTTS5GMNHANCNFSM4XATP5SQ>
.
Hey!
As you know today we do gRPC over TLS. In general, I don't know what to expect. @mmlb proposed to remove it until we figure something out and I started doing it until I stopped because I think I want to know more first.
My expectation for TLS is to be able to use it as a way to identify a user and to be able to figure out in the future what that user can do. Almost like a service account for kubernetes.
Right now we are far away from it and as @detiber pointed out here #266 the way we do TLS now is not even flexible enough.
So, what do we want? We can remove TLS for now, demanding it to some other actors like Traefik, NGIX, and similar (it won't be part of sandbox, but we should write tutorials about how to run Tinkerbell gRPC/HTTP API under TLS and cycle back on this topic later... Or something else!
The text was updated successfully, but these errors were encountered: