security: look into restricting access to the kubernetes API (only where needed)

[v1k0d3n]

i would like to look at policies that could restrict access from all services having direct access to the API (wherever possible/within reason). perhaps a PoC with something like https://github.com/aporeto-inc/trireme could be used, or possibly calico/romana?

[intlabs]

This has been a long ongoing issue with Kubernetes, though I think that enabling ABAC in the cluster would be a big step in the right direction:

• How to _not_ create a service account? kubernetes/kubernetes#16779
• Make serviceAccountName a pointer and change defaulting kubernetes/kubernetes#17445

We should also review the security of the Kubernetes Entrypoint container - and possibly look toward updating this with a server-client model (maybe as part of #88), which would be fairly easy to do:

• 'Server' lives in kube-system namespace, consisting of K8S API watcher, ETCD and nginx containers:
  1. K8s Watcher stores selected job/service/daemon status in ETCD.
  2. Nginx provides read-only proxy of data for ETCD to pods, potentially with http basic auth.
• 'Client' container's contents could be reduced to a very simple script that simply curls the Nginx container, without needing any access to the K8s API.

[v1k0d3n]

also, i would like our internal security group look at Kubernetes NetworkPolicy and calico/canal Advanced NetworkPolicy.

A couple areas of interest here:
All charts/manifests should include some form of NetworkPolicy (not all addressed today):

• Network Policy Configuration
• API Reference and information
• Security Context Restrictions
• Authentication
• Using Authorization Plugins
• Using Secrets with Helm

Advanced NetworkPolicy which is offered by Calico or other SDN's:

• Calico Advanced Network Policy

[v1k0d3n]

we can track this as a larger issue, but it is unrelated to a release...so the issue is going to be closed for now.