Skip to content

Cloud Security

1. Cloud Native Security

Overview
  • Followed a layered approach that is based on defense in depth approach.
  • The 4C layers of Cloud Native Security
    • Cloud Datacenter
    • Cluster (Kubernetes)
    • Container
    • Code
Cloud Data Center
  • Cloud Provider: Their hardware their policy
  • In-house infrastructures
    • Physical security
    • Network access
    • Database access (etcd for Kubernetes)
Cluster (Kubernetes)
  • RBAC Authorization
  • Authentication
  • Encryption
  • Network Policies
  • TLS for Kubernetes Ingress
Container
  • Vulnerability Scanner/OS Dependencsy Security
  • Privilege Control/Disabling
  • Container runtime isolation
Code
  • Secure communication over TLS
  • Port range limitation
  • Security of external library dependency
  • Static code analysis
  • Dynamic code security (SQL injection, cross-site scripting, ...)

2. Cluster Security: Kubernetes

Authentication
  • Users:
    • Normal users (managed by host system/remote management like LDAP)
    • Service accounts (internal to K8s)
  • Users can present a valid certificate signed by the cluster's CA (Certificate Authority) are considered authenticated.
Authentication hands-on
Confirms that Rancher setup is up and ready 
kubectl get nodes

Extract configuration information 
cat ~/.kube/config
  • Keep a record of the following fields (or do this in separate terminals)
    • certificate-authority-data
    • server
    • client-certificate-data
    • client-key-data
Create a new user account
  • New user account is called student:
sudo useradd -s /bin/bash -d /home/student -m -G docker student
sudo su - student
  • Try running kubectl commands now:
kubectl get nodes
kubectl get svc

Setup authorization to access K8S
  • As student, run the following command:
mkdir .kube
  • Next, create a file called config inside .kube with the following contents:
    • Replace COPY_FROM_ABOVE with the corresponding values of the corresponding fields above. 
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: COPY_FROM_ABOVE
    server: COPY_FROM_ABOVE
name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: student
  name: student@kubernetes
current-context: student@kubernetes
kind: Config
preferences: {}
users:
- name: student
user:
    client-certificate-data: COPY_FROM_ABOVE
    client-key-data: COPY_FROM_ABOVE
  • Try running kubectl commands now:
kubectl get nodes
kubectl get svc

Challenge

Adding at least another Kubernetes cluster from one of your classmates' experiment to your student account. In other words, one account can have access to multiple K8S cluster.

RBAC Authorization
  • Kubernetes uses the rbac.authorization.k8s.io API group to drive RBAC-based authorization decisions,
  • By default, Kubernetes clusters are often launched with RBAC:
kubectl describe pods kube-apiserver -n kube-system | grep authorization
  • RBAC API: Role, ClusterRole, RoleBinding, ClusterRoleBinding.
  • Role: sets permissions within a particular namespace
kubectl get role --all-namespaces
kubectl describe role system::leader-locking-kube-controller-manager -n kube-system
  • ClusterRole: set permission for non-namespaced resources
kubectl get clusterrole --all-namespaces
kubectl describe clusterrole cluster-admin
  • RoleBinding binding grants the permissions defined in a role to a user or set of users.
  • ClusterRoleBinding grants that access cluster-wide.
kubectl get RoleBinding --all-namespaces
kubectl get ClusterRoleBinding
  • What resources are available and what verbs are applicable?
kubectl api-resources --sort-by name -o wide
Kubernetes Ingress
  • Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster.
  • Traffic routing is controlled by rules defined on the Ingress resource.
  • Ingress is managed by Ingress Controllers.
  • There are many diffferent Ingress Controllers

3. Container Security

Pod Security Standards
  • Pod security will influence container security.
  • Three policies:
    • Privileged
    • Baseline
    • Restricted
  • Cummulative and range from highly permissive to highly restrictive
Privileged
  • Purposely open, entirely unrestricted
  • Enable system- and infrastructure-level workloads
    • Implied understanding that these workloads are run as privileged/trusted users.
  • Absence of restrictions and allow-by-default mechanism
Baseline
  • Streamline adoption for common containerized workloads
  • Prevent known privilege escalations
  • Example capabilities (Linux capabilities) enabled in baseline
    • AUDIT_WRITE
    • CHOWN
    • DAC_OVERRIDE
    • FOWNER
    • FSETID
    • KILL
    • MKNOD
    • NET_BIND_SERVICE
    • SETFCAP
    • SETGID
    • SETPCAP
    • SETUID
    • SYS_CHROOT
  • Linux full capability list
Restricted
  • Enforce Pod hardening best practices at the expense of compatibility
  • Target security-critical applications and lower-trust users
  • Example policy:
    • Disable privilege escalation
    • Containers must run as non-root
    • Drop ALL capabilities and only allow NET_BIND_SERVICE.