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
A discussion about a use case with Nginx I thought about and the questions I have that are related to, I'm putting this in Q&A so that we could start looking at the prerequisites.
The context
So when I was working on a mission, we had several backend rest apis, protected by a gateway that requires the need of api keys to be passed by, a java gateway (serving as a layer of BFF with some security check with the JWT sent), an nginx reverse proxy (serving as another layer of BFF) and the frontend making the calls.
The main purpose of this architecture was to avoid the user to know the api keys sent to the back. The problem is that the nginx reverse proxy was set statically and would only redirect to our java gateway. And we would had to code manually the routes etc. to HTTP routes of the main gateway of our company.
Now in a wonderful world I would have preferred to delete the java gateway, implement the JWT check on the respective apis (at the back and not the gateway), and finally dynamically generate the nginx configuration.
So it would look like something like this
┌─────┐
┌──►│API A│
│ └─────┘
┌───────┐ ┌───────┐ │
│ │ │ BACK │ │ ┌─────┐
│ FRONT ├───►│ FOR ├───┼──►│API B│
│ │ │ FRONT │ │ └─────┘
└───────┘ └───────┘ │
│ ┌─────┐
└──►│API C│
└─────┘
To be honest I don't have this use case anymore at the moment (because I changed of mission), but in the future this is definitely something that I will need and that would be powerful to use.
What would I like to do
I'm a newbie with Cue and Dagger but not against learning more in details (even more with cue) so feel free to redirect me to some docs if you have some tips.
The way I see it is that my DAG will use at least two packages that doesn't exist (yet). I know that Dagger have a proposal to simplify some core concepts (#997) and I will take care of that on the questions below.
Retrieve the secrets on Vault
Because the API keys shouldn't be known (and not logged in the CI), I would need a package that accepts some inputs (with secrets inside to log in Vault) and store the results into secrets.
Now Vault can work perfectly with REST calls but we will need to handle the different kind of authentication (LDAP, User, Token, etc.) and the notion of namespaces that are available in Vault Enterprise. (It's an http header but still need to be taken care of)
Generate a valid Nginx configuration
Now this is the tricky part and I'll need @grouville to help me to find the best way to make a DAG standard for generating an nginx config.
An Nginx configuration can be a lot of things (as the example shows), this means that we need to draw a line between what the package can do by itself and what it won't handle. Or maybe we'll be able to deal with everything correctly.
For my use case I have doubt about the best way to do this:
Should I give to the package an nginx template and let it fill in the values with the secrets ?
Should I input what I want based on the package (like the server's port, the locations to generate, if it's grpc or not) and it will generate an nginx conf file or multiple files.
At the end we could also let the package handle the generation of the self signed certificates from Let's encrypt if we want to use HTTP2 or QUIC.
Inject the nginx config into a docker image
For this I know there is a docker package from the dagger universe so it should be fine.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi everyone 👋
A discussion about a use case with Nginx I thought about and the questions I have that are related to, I'm putting this in Q&A so that we could start looking at the prerequisites.
The context
So when I was working on a mission, we had several backend rest apis, protected by a gateway that requires the need of api keys to be passed by, a java gateway (serving as a layer of BFF with some security check with the JWT sent), an nginx reverse proxy (serving as another layer of BFF) and the frontend making the calls.
The main purpose of this architecture was to avoid the user to know the api keys sent to the back. The problem is that the nginx reverse proxy was set statically and would only redirect to our java gateway. And we would had to code manually the routes etc. to HTTP routes of the main gateway of our company.
Now in a wonderful world I would have preferred to delete the java gateway, implement the JWT check on the respective apis (at the back and not the gateway), and finally dynamically generate the nginx configuration.
So it would look like something like this
To be honest I don't have this use case anymore at the moment (because I changed of mission), but in the future this is definitely something that I will need and that would be powerful to use.
What would I like to do
I'm a newbie with Cue and Dagger but not against learning more in details (even more with cue) so feel free to redirect me to some docs if you have some tips.
The way I see it is that my DAG will use at least two packages that doesn't exist (yet). I know that Dagger have a proposal to simplify some core concepts (#997) and I will take care of that on the questions below.
Retrieve the secrets on Vault
Because the API keys shouldn't be known (and not logged in the CI), I would need a package that accepts some inputs (with secrets inside to log in Vault) and store the results into secrets.
Now Vault can work perfectly with REST calls but we will need to handle the different kind of authentication (LDAP, User, Token, etc.) and the notion of namespaces that are available in Vault Enterprise. (It's an http header but still need to be taken care of)
Generate a valid Nginx configuration
An Nginx configuration can be a lot of things (as the example shows), this means that we need to draw a line between what the package can do by itself and what it won't handle. Or maybe we'll be able to deal with everything correctly.
For my use case I have doubt about the best way to do this:
At the end we could also let the package handle the generation of the self signed certificates from Let's encrypt if we want to use HTTP2 or QUIC.
Inject the nginx config into a docker image
For this I know there is a docker package from the dagger universe so it should be fine.
Send the docker to a kubernetes and run it
Same as above, "there's a package for that" 👍
Beta Was this translation helpful? Give feedback.
All reactions