jortel
commented
2 years ago Seems simpler for the operator to install (configure) Tackle components with authn/authz disabled all together for local (single-user) deployments. Also, the Keycloak deployment could be simplified quite a bit given is extremely light usage in the tackle environment. The documentation indicates it can be deployed with an embedded H2 database. This would reduce to a single pod (even for large deployments).
When running Tackle on a laptop, the resources are constrained and running only core services allows to grant more resources to tasks and user interface. One component that is consuming resources is the Keycloak service.
It consumes 1 pod for the PostgreSQL database and 1 pod for the Keycloak application, with a start time of about 2 minutes. And on a laptop, Keycloak doesn't really make sense, since the only user (
tackle) is administrator. There is no remote authentication provider to proxy.The authorization layer could also be done in Tackle Hub. This would allow to map it closer to the application domain, allow to easily add roles for add-ons and remove the dependency on a 3rd-party component for a core feature. And with the hub and spoke design, there is no reason for the other services to interact directly, so the authorization is only required at the Tackle Hub level.
The only benefit of Keycloak is that it is an OpenID Connect (OIDC) Provider that the other services can use for authn/authz. If Tackle Hub is able to act an OIDC Provider as well, we can remove Keycloak from the equation in constrained deployments. In that case, the authentication would be based on the Tackle Hub database.