We started discussing securing nginx controller with side car proxy

The availability of the proxy alleviates the concerns from the application so the application continues on its default configuration without any tweaks while the proxy enables authentication of clients based on sub-requests. If the sub-requests return error in the 401 range, the call is prohibited. Otherwise a success code of 200 is returned which allows the calls to propagate to the application. 

Ngx_http_auth_request_module and envoy proxy demonstrate this very well. These access modules can be turned on or off.  They enable authorization on an incoming request based on the result of a subrequest usually by replacing the address in the request to where the subrequest will be sent. 

This results in a configuration like below:  

location /private/ {      

auth_request /auth;     ...  

}  

 location = /auth {  

    proxy_pass ...  

    proxy_pass_request_body off;   

   proxy_set_header Content-Length "";  

    proxy_set_header X-Original-URI  

  $request_uri;  

} 

These access modules work best with containers or microservices since they usually have endpoints which we want to secure. 

These access modules work tightly with the primary application, but are placed inside their own process or container, which provides a homogeneous interface for platform services across languages and implementations of the application.

The main advantages of the side car proxy are :

1) It is independent from the primary application in terms of environment and programming language

2) A sidecar can access the same resources as the primary application. It can even be used for monitoring.
3) There is no latency in the communication between the side car proxy and the main application
4) When the applications don't provide an extensibility mechanism, the side car can extend the functionality often in its own container.