Replies: 4 comments
-
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. But this is only my 2 cents. |
Beta Was this translation helpful? Give feedback.
-
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>
.
|
Beta Was this translation helpful? Give feedback.
-
I would be in favor of making it toggle-able. So on by default, but have an env var, cli flag, etc that would disable it. |
Beta Was this translation helpful? Give feedback.
-
quick note as this was discussed in the community meeting today. After today's community meeting we had an agreement that TLS should be removed. One thing I didn't grasp from Gianluca's comments above is that he's advocating mTLS. I had the opinion that mTLS is great and something we should probably strive for but Tinkerbell as a project is not yet ready for it. |
Beta Was this translation helpful? Give feedback.
-
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!
Beta Was this translation helpful? Give feedback.
All reactions