Cloud Security

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

CAREERCloud security failures cross technical layers

Cloud incidents rarely fit into only one category. A vulnerable application, network exposure, workload identity, and excessive storage permissions can combine into one attack path.

The U.S. Department of Justice’s Capital One case summary describes an intrusion through a misconfigured web application firewall that enabled unauthorized access to cloud-hosted data. The case is a useful reminder to evaluate the complete path from an externally reachable workload to its identity and permitted resources.

In a Kubernetes security review, ask:

What can an attacker reach after compromising this container?
Does the Pod receive a service-account token it does not need?
Which API objects and external cloud resources can that identity access?
Do network and admission policies limit lateral movement?
Would audit logs reveal the access quickly enough to respond?

Security engineers are expected to connect preventive controls with detection, incident response, and evidence—not merely produce a hardening checklist.

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, …)

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

INFOConfirms that Rancher setup is up and ready

 kubectl get nodes
 

INFOExtract 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

INFOCreate 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
 

INFOSetup 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

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.