Document the security aspects to secure K8s

[andrewtpham]

This is a continuation of the K8s documentation on how to best manage.

Use this card to track security documentation on K8s and our infrastructure

[jassem123]

Roadmap:

We will address Kubernetes cluster security a layer at a time a.k.a The 4C's of Cloud Native Security; which are Cloud provider, Clusters, Containers, and Code .

Cloud Provider:

Follow recommendations by Digital Ocean to securely run a DOKS.

1. Network access to API Server: access to the kubernetes control plane should be regulated by network access control lists and restricted to the set of IPs addresses to administer the cluster. (Currently should contain only @TAnas0 's IP )
2. Network access to Nodes: Nodes must only accept connections from the control plane on the specified ports, and accept connections for services in Kubernetes of type NodePort and LoadBalancer (Configured via network access control lists)
3. Access to etcd: should be limited to the control plane only. using etcd over TLS is recommended since it contains critical data (secrets, cluster's state), isolating etcd in a separate disk and encrypting the latter's data is a plus. (see this)

Clusters:

Access to the Kubernetes API should be controlled by first authenticating and authorizing distant users (configured at step 1) and wiring them depending on their perspective service accounts .

1. Prevent service account token automounting on pods:
   Not every pod needs the ability to utilize the API from within itself. so there is no need for the app to contact the API server, and therefore a mounted token is unnecessary.
   in order to add a service account run:

kubectl create -f - <<EOF 
apiVersion: v1
kind: ServiceAccount
metadata:
    name: sa1
automountServiceAccountToken: false
EOF

later the Pod is run with service account “sa1” assigned to it:

kubectl create -f - <<EOF 
apiVersion: v1
kind: Pod
metadata:
    name: sa1-pod
spec:
    serviceAccountName: sa1
    containers:
    - name: nginx
       image: nginx: latest
       ports:
       - containerPort: 80
EOF

Alternatively, disabling the account service mount can be done when creating the pod :

kubectl create -f - <<EOF 
apiVersion: v1
kind: Pod
metadata:
    name: sa1-pod
spec:
    serviceAccountName: sa1
    autmountServiceAccountoken:false
    containers:
    - name: nginx
       image: nginx: latest
       ports:
       - containerPort: 80
EOF

2. Grant specific users to RoleBindings\ClusterRoleBindings
3. Use Roles and RoleBindings instead of ClusterRoles and ClusterRoleBindings:
   As their name state, ClusterRoles and ClusterRoleBindings aplly to all the namespaces of the cluster.
   While Roles and RoleBindings are assigned to a specific namespace.

Containers:

Might be out of the scope of this ticket, but there's some recommendations to follow while building a container:
a. Container Vulnerability Scanning and OS Dependency Security.
b. Disallow privileged users: work with users that have the least level of operating system privilege necessary in order to carry out the goal of the container.
c. Preventing containers from loading unwanted kernel modules:
On Linux distributions, you can do that by creating a file /etc/modprobe.d/kubernetes-blacklist.conf with contents like:

# vulnerabilities, and is not well-maintained.
blacklist dccp

# SCTP is not used in most Kubernetes clusters, and has also had
# vulnerabilities in the past.
blacklist sctp 

Finally, signing containers and establishing a system of trust for deployed applications.

Code:

Access should to be enabled only over TLS
Reduce opened ports range..

[andrewtpham]

@TAnas0 @jassem123 @andrewtpham to discuss sometime Friday the points laid out above. Once agreed, @jassem123 can open a PR with the documentation.