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. 

NGINX has always been a reverse proxy. The authentication provided by a reverse proxy is not available from Kubernetes Services.  Therefore, a reverse proxy is sometimes run in the same pod as the application in a side car container. The side car proxy is exposed only to the world outside the pod while keeping the connection between the application and the proxy private. Envoy proxy demonstrates this and the Istio plugin injects this proxy inside the pod. All http port 80 traffic then goes through the pod and a corresponding request is made to the application. Unless the traffic entering the side-car proxy has basic authentication, it does not make a request to the application. 

# Kubernetes deployment to deploy Sidecar proxy + application in a single pod,  

apiVersion: apps/v1 

kind: Deployment 

metadata: 

name: nginx-deployment 

labels: 

app: example-application 

spec: 

replicas: 1 

selector: 

matchLabels: 

app: example-application 

template: 

metadata: 

labels: 

app: example-application 

spec: 

containers: 

- name: sidecar-proxy 

image: example-application-sidecar-proxy 

imagePullPolicy: Always 

ports: 

- containerPort: 80 

- name: application 

image: example-application 

imagePullPolicy: Always 

The basic auth used with the proxy can be specific to clients and not necessarily to the users. Any Identity Access Module can authenticate and authorize the user which can then then translate to a token over client communications with the application.  This is called client credential workflow where the clients treat a guest user or an identified user the same and an IAM module is responsible to ensuring only valid users are able to access the client. Thus, user sends requests from outside world to the IAM, then to the client, then to the proxy and finally to the application. 

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.

The support for mutual authentication in GoLang has its limitations:

Mutual authentication can be best described by the presence of two files – keystore and truststore.

A keystore imports a key and a certificate to identify the server to its clients.

A truststore imports only certificates that the clients make to validate itself to the server.

Together the keystore enables the server to be validated to the clients and the truststore enables the clients to be validated to the servers.

The support for these in GoLang is rather limited:

Golang.org/x/crypto/pkcs12 provides an ability to make SafeBags and ShroudedBags. A keystore or a truststore is essentially a collection of safebag or shroudedbag. The former is used to enclose certificates and the latter is used to enclose the private key.

However, pkcs12 does not support making truststores and is left for the caller of the library to implement. The support for keystore is made possible with the help of Encode method which takes a private key and a certificate.

Without the private key the Encode method could be tweaked to make only a truststore however it becomes the task of the caller to add certificates to the truststore as they become available. The ability to pass the certificate to the caller depends exclusively on the clients as they come up. It the clients are known beforehand; their certificates are also known beforehand. However, this is not always the case as clients come-up dynamically and they need to register their certificates.

Most applications are unaware of the clients except for their own internal clients used with say the command line interface. Moreover, these applications delegate the transport layer security to the keystore and truststore files assuming that automations involving tools like keychain will automatically add the certificate to the concerned file. 

Yet this is not really the case and clients need to add their certificates to the pre-existing truststore so that the Kubernetes operators can install and provision the application with transport layer security. Currently this is left as Do-It-Yourself approach both in the standard golang pkcs12 library as well as the upcoming go-pkcs12 library.   

An alternative to using keystore and truststore is to use nginx ingress controller with side car proxy.