Infisical
Make backend stateless
The current backend is not stateless so it cannot be scaled up in Kubernetes.
Details
During the first login, it gets the salt and the serverpublic key but during the next call, it won’t be guaranteed to go back to the same backend. So this line of of code may not have any data for the first login call: https://github.com/Infisical/infisical/blob/main/backend/src/controllers/authController.ts#L94
What we need
We need to think about how we can save such data somewhere else temporarily to make the backend stateless again.
@maidul98 I think that the solution here is pretty easy! We just need to store that data in a specified temp folder. Once did this, if you want to run the application inside a scalable architecture you have just to mount a volume under the temp folder so you can make data persistent and accessible by the entire cluster. If you want to run the application in a monolith way this will be not a problem.
With this solution you will add complexity (mount the volume) only in scalable architectures leaving unchanged monolith architectures
This is a great idea and it makes sense to me. If you have time to push a PR, feel free! If not, I can also do it
@maidul98 Yes I will do it. I think that we also have to do the documentation for this, I'm right?
Awesome! And for ease you can add the documentation in the PR and I will place them in their appropriate spot
@maidul98 @mv-turtle what priority does this issue have? Asking cause I am busy in this period and I need to schedule it.
It's not a blocker for anyone at the moment so it can wait a bit. Did you have a date in mind on when you'll be able to complete it?
sure, in 1/2 weeks (assuming that I can work on that) should be done! I will update the issue in case I will not able to do it, for now just leave me as assignee.
hey @CristianBelli01k, just checking in on this. Let me know if you need help on this or if you don't currently have bandwidth to complete it
Hey @maidul98 I'm currently too busy to finish this... I started and saw some additional problems but I did something that is not pushable as WIP. Let me update you with the info I've found (so if you can resolve this issue you don't have to study the entire solution).
I found this issue in two files: authController.ts passwordController.ts
We have to create a 'cache' collection in our DB that will store values now store into
const clientPublicKeys: any = {};
With this, we will be able to share through multi-container clusters the client's public keys.
We also need to store into this collection the server's public key cause will be used to validate the request in the second step.
This is an example of the object that we will store:
{
"uuid": "cfadd37a-38b8-4d5f-bf09-03c7d6220cae",
"email": "[email protected]",
"clientPublicKey": "blablabla",
"serverPublicKey": "blablabla",
"serverBInt": 10000000000000
}
How the final flow should look like:
- User calls step 1
- Server will generate data, store it in the collection and return to the frontend: serverPublicKey, salt and UUID.
- User calls step 2, frontend will pass to the API also the UUID
- Server will retrieve (by matching UUID and email) the object into collection
- Server will set its own public key with
server.setPublicKey(obj.serverPublicKey); - Do the same flow it already does
- On successful login delete the object in the collection
⚠️ This is a draft idea to resolve this issue, I'm not 100% sure that this will work fine without having bugs.
Let me know what you think about that and let me know if you will start to implement.
@CristianBelli01k thanks for looking into this. I think you are write in that a DB collection will be the simplest solution. I think what we can also add is a TTL to each item so that in the event the user abandons the login workflow, the collection will get auto deleted after some time. I'll look to implement this sometime next week unless someone wants to take a stab at it