We had a discussion about prooph/micro-cli security in the chat with @prolic @bweston92 @danizord
I'd like to summarize the discussion here and identify needed steps to improve security and/or document the approach so that questions about security can be answered easily.
prooph/micro-cli - replace PHP logic for http routing + auth with Nginx api gatewaay
Daniel Gimenes @danizord 14:50
yeah, I see it like that: Expressive as pipeline for http request -> response, and micro is another pipeline in between for command -> event[]
Alexander Miertsch @codeliner 14:51
yeah, exactly @danizord
you can however decide to replace expressive with an Nginx api gateway and route to prooph/micro driectly
that is the idea behind micro-cli
security considerations - secure every container VS secure once for all services forming an application
Bradley Weston @bweston92 15:06
@prolic your service would still need to validate that auth
headers are ok but also an attack vector
especially if you're using DigitalOcean say, where private ips can be access by any vm they host
Alexander Miertsch @codeliner 15:08
@bweston92 regarding security. It depends on your api gateway. Often https is terminated after request passes the api gateway for example
so why reauthenticate the request in every service if the api gateway already did?
Bradley Weston @bweston92 15:09
@codeliner if there is someone inside the network through another vunrability in a web app say, they can access that service directly
Alexander Miertsch @codeliner 15:10
true for monoliths, too. If you found a way in you can access everything. See no difference
Daniel Gimenes @danizord 15:12
I'd feel a lot more confortable parsing/validating a JWT in PHP side
Bradley Weston @bweston92 15:12
@danizord why not have it on both?
The API gateway can basically "decrypt" the JWT, ensure the expirary etc. Pass it to the service, that service then checks it against an authentication service for true validity
That way not every service needs to know the decrypt key/method either
Alexander Miertsch @codeliner 15:14
The idea of micro in short:
old monolith:
http layer
framework modules/bundles/packates
service layer
model
database
queue
cache
...
micro:
http layer -> nginx
framwork modules -> no modules, each prooph/micro service runs in its own docker container/process
service layer -> pure functions
model -> prooph/micro driven
database -> event-store, projections in own docker containers, own services
queue -> own service
cache -> no need, you have projections
... everything possible
Bradley Weston @bweston92 15:15
@codeliner I know th benefits, but what I'm saying is every service still needs to check for authentication
@bweston92 why? You don't expose any ports
Nginx is linked to php-fpm container
only Nginx answers external requests
so only Nginx needs to perform authentication
Bradley Weston @bweston92 15:16
You don't expose them to the outside world, but if someone gets access in any way you've got no protection
Alexander Miertsch @codeliner 15:17
yeah but again. That problem always exists
Bradley Weston @bweston92 15:17
But eliminating at every step you can makes it better
Alexander Miertsch @codeliner 15:17
and much slower, more complex ....
Bradley Weston @bweston92 15:18
But more secure
It doesn't have to be complex either, middleware in the service would solve it
...
Sascha-Oliver Prolic @prolic 15:24
If I am able to pass the security I can go in every container
Bradley Weston @bweston92 15:24
Not at all, if the way you got in is through someones bad coding on the web app
...
Bradley Weston @bweston92 15:32
https://image.slidesharecdn.com/anauthenticationandauthorizationarchitectureforamicroservicesworlddavidferriera-160810013550/95/an-authentication-and-authorization-architecture-for-a-microservices-world-12-1024.jpg
Alexander Miertsch @codeliner 15:34
@danizord
| why doing security checks in an external layer in first place if you can do easily with a PHP middleware?
expressive is an external layer, at least for your model. It runs inside the same PHP process but your model rely on the correct work done by your middleware layer
If you move that layer to Nginx nothing changes for your model
you just get a non blocking way of handling Authentication and only forward real work to PHP
@bweston92 @sandrokeil Is it possible to deny access and only whitelist a specific container? That would solve the issue that PHP-FPM can be accessed by every other container in the network
ah wait, we can put only Nginx and PHP-FPM in one network. That should do the trick, right?
Bradley Weston @bweston92 15:38
@codeliner I don't know about docker swarm
But inside of Kubernetes you can
Alexander Miertsch @codeliner 15:39
Yeah, it is like a Kubernetes Pod
Daniel Gimenes @danizord 15:40
@codeliner @bweston92 yeah I saw a guy doing that with this new docker-compose v3
Bradley Weston @bweston92 15:40
@prolic " I don't know about docker swarmBut inside of Kubernetes you can"
@danizord that sounds like it would do the trick
Alexander Miertsch @codeliner 15:41
We should play with both Docker Infra Kit and Kubernetes
We had a discussion about prooph/micro-cli security in the chat with @prolic @bweston92 @danizord
I'd like to summarize the discussion here and identify needed steps to improve security and/or document the approach so that questions about security can be answered easily.
prooph/micro-cli - replace PHP logic for http routing + auth with Nginx api gatewaay
Daniel Gimenes @danizord 14:50
yeah, I see it like that: Expressive as pipeline for http request -> response, and micro is another pipeline in between for command -> event[]
Alexander Miertsch @codeliner 14:51
yeah, exactly @danizord
you can however decide to replace expressive with an Nginx api gateway and route to prooph/micro driectly
that is the idea behind micro-cli
security considerations - secure every container VS secure once for all services forming an application
Bradley Weston @bweston92 15:06
@prolic your service would still need to validate that auth
headers are ok but also an attack vector
especially if you're using DigitalOcean say, where private ips can be access by any vm they host
Alexander Miertsch @codeliner 15:08
@bweston92 regarding security. It depends on your api gateway. Often https is terminated after request passes the api gateway for example
so why reauthenticate the request in every service if the api gateway already did?
Bradley Weston @bweston92 15:09
@codeliner if there is someone inside the network through another vunrability in a web app say, they can access that service directly
Alexander Miertsch @codeliner 15:10
true for monoliths, too. If you found a way in you can access everything. See no difference
Daniel Gimenes @danizord 15:12
I'd feel a lot more confortable parsing/validating a JWT in PHP side
Bradley Weston @bweston92 15:12
@danizord why not have it on both?
The API gateway can basically "decrypt" the JWT, ensure the expirary etc. Pass it to the service, that service then checks it against an authentication service for true validity
That way not every service needs to know the decrypt key/method either
Alexander Miertsch @codeliner 15:14
The idea of micro in short:
old monolith:
http layer
framework modules/bundles/packates
service layer
model
database
queue
cache
...
micro:
http layer -> nginx
framwork modules -> no modules, each prooph/micro service runs in its own docker container/process
service layer -> pure functions
model -> prooph/micro driven
database -> event-store, projections in own docker containers, own services
queue -> own service
cache -> no need, you have projections
... everything possible
Bradley Weston @bweston92 15:15
@codeliner I know th benefits, but what I'm saying is every service still needs to check for authentication
@bweston92 why? You don't expose any ports
Nginx is linked to php-fpm container
only Nginx answers external requests
so only Nginx needs to perform authentication
Bradley Weston @bweston92 15:16
You don't expose them to the outside world, but if someone gets access in any way you've got no protection
Alexander Miertsch @codeliner 15:17
yeah but again. That problem always exists
Bradley Weston @bweston92 15:17
But eliminating at every step you can makes it better
Alexander Miertsch @codeliner 15:17
and much slower, more complex ....
Bradley Weston @bweston92 15:18
But more secure
It doesn't have to be complex either, middleware in the service would solve it
...
Sascha-Oliver Prolic @prolic 15:24
If I am able to pass the security I can go in every container
Bradley Weston @bweston92 15:24
Not at all, if the way you got in is through someones bad coding on the web app
...
Bradley Weston @bweston92 15:32
https://image.slidesharecdn.com/anauthenticationandauthorizationarchitectureforamicroservicesworlddavidferriera-160810013550/95/an-authentication-and-authorization-architecture-for-a-microservices-world-12-1024.jpg
Alexander Miertsch @codeliner 15:34
@danizord
| why doing security checks in an external layer in first place if you can do easily with a PHP middleware?
expressive is an external layer, at least for your model. It runs inside the same PHP process but your model rely on the correct work done by your middleware layer
If you move that layer to Nginx nothing changes for your model
you just get a non blocking way of handling Authentication and only forward real work to PHP
@bweston92 @sandrokeil Is it possible to deny access and only whitelist a specific container? That would solve the issue that PHP-FPM can be accessed by every other container in the network
ah wait, we can put only Nginx and PHP-FPM in one network. That should do the trick, right?
Bradley Weston @bweston92 15:38
@codeliner I don't know about docker swarm
But inside of Kubernetes you can
Alexander Miertsch @codeliner 15:39
Yeah, it is like a Kubernetes Pod
Daniel Gimenes @danizord 15:40
@codeliner @bweston92 yeah I saw a guy doing that with this new docker-compose v3
Bradley Weston @bweston92 15:40
@prolic " I don't know about docker swarmBut inside of Kubernetes you can"
@danizord that sounds like it would do the trick
Alexander Miertsch @codeliner 15:41
We should play with both Docker Infra Kit and Kubernetes