Colt McNealy
11/29/2023, 4:20 PMMoshe Eshel
12/05/2023, 4:43 PMGwen Shapira
12/05/2023, 5:16 PMRobert Treat
12/06/2023, 7:59 PMHarsh Gupta
12/07/2023, 8:28 PMStefan Krawczyk
12/20/2023, 5:48 AMColt McNealy
12/30/2023, 4:23 PMFoo
app, and the Foo
app uses Keycloak as an auth server. For now, each customer gets their own Foo
app (single-tenant), but that won't always be the case. We use Keycloak in the control plane to manage customers logging in to the control plane. We've got K8s operators in the data planes which talk to the control plane, ask what to deploy, then deploy the relevant Foo
apps.
We have two options here:
1. Each Foo
app in the data plane uses the same keycloak cluster running in the central control plane
2. We deploy Keycloak in each data plane, and the Foo
apps use the local Keycloak.
Option 2 is slightly more complex than option 1 because we will be using the control plane to manage credentials for the Foo
app. For example, there will be a page on the control plane where a customer can click "Create API Key/serviceaccount/princpal/whatever", and it will do some magic and then after a second or two it will present a key + secret to the user to be downloaded and saved immediately.
In option 2, we would have to have the control plane send the secret down to the data plane so the operator could create the keycloak client locally. In option 1, the control plane web-app just creates the keycloak client, then the only thing passed down to the data plane is the client id (which isn't a secret).
Another advantage to option 1 is that there is now only one auth server to audit.
The advantages to option 2 are isolation (smaller blast radius in case of security incident), scalability, and the fact that data plane doesn't need to do cross-region communication to validate a token. Option 2 makes it feasible to have a dedicated Realm per Foo
app, but that's not feasible in Option 1 because of limitations on how many realms Keycloak can handle. Lastly, some customers might require fully-dedicated Keycloak, for example if they want to use their own SSO.Graeme Watt
01/12/2024, 11:32 AMColt McNealy
01/23/2024, 2:02 AMGwen Shapira
01/23/2024, 2:08 AMvaibhav
01/24/2024, 2:11 PMGwen Shapira
01/26/2024, 6:31 PMMoshe Eshel
02/08/2024, 8:02 AMpull
(i.e. downloads) the image from some repository (or registry).
This image has to be stored somewhere before it is executed, this is usually on the client machine.
So, if we have multiple clients for the same image in one geographical location, a sensible optimization for download speed, is a pull-through cache - every client pulling will go through the cache, so that a second request for the same image will be served from the cache - great! Most registries do not support this for private registries, but here is a project that can help - awesome.
Now the next problem - how do I save on the client storage? What I would really like is the following idea:
1. local (az) Pull-through cache saves to a NAS (EFS, NFS whatever you have).
2. Clients have some disk volume where they look for images before pulling from network, and this would be the save NAS folder where the pull-through cache saves the files - but it will be defined as their own image storage
Does anyone know of such a tool? maybe there is a K8S feature that provides such a thing?
My research points to Podman as a client that separates image storage from other container related storage and so would possible support such a model - but I couldn't reason well about it, most of the documentation focuses around the star.gz thing
ThanksLucas Stephens
02/15/2024, 5:58 AMColt McNealy
03/05/2024, 12:44 AMDaniel Chaffelson
03/05/2024, 9:22 AMLucas Stephens
03/07/2024, 1:20 AMDaniel Zivkovic
03/10/2024, 3:02 PMColt McNealy
03/12/2024, 3:57 PMSean Falconer
03/13/2024, 3:27 PMLucas Stephens
03/16/2024, 8:38 PMLucas Stephens
03/22/2024, 3:32 PMLucas Stephens
03/28/2024, 11:10 PMJeffrey Sherman
03/29/2024, 2:57 PMMoshe Eshel
03/31/2024, 1:15 PMJeffrey Sherman
04/01/2024, 2:00 PMDaniel Chaffelson
04/03/2024, 8:35 AMColt McNealy
04/15/2024, 3:38 PMLucas Stephens
04/24/2024, 10:56 PM