Assessments

Chapter 1

1. Scaling, operational cost, and longer release cycle.
2. Master components run on the master node. These components are responsible for the management of the worker nodes. The master components include kube-apiserver, etcd, kube-scheduler, kube-controller-manager, cloud-controller-manager, and dns-server.
3. Kubernetes Deployments help scale pods up/down based on labels and selectors. Deployments encapsulate replica sets and pods. The YAML spec for a Deployment consists of number of instances of pods and template, which is identical to a Pod specification.
4. OpenShift, K3S, and Minikube.
5. Kubernetes environments are highly configurable and are composed of a myriad of components. Configurability and complexity with insecure defaults is a big cause of concern. Additionally, the compromise of master components in cluster is the easiest way to cause a breach.

Chapter 2

1. Pod.
2. Network namespace and IPC namespace.
3. A placeholder to hold a network namespace for other containers.
4. ClusterIP, NodePort, LoadBalancer, and ExternalName.
5. Ingress supports layer 7 routing and doesn't require extra load balancers from the cloud provider, while LoadBalancer services require one load balancer per service.

Chapter 3

1. Threat modeling is an iterative process that starts at the design phase.
2. End user, internal attacker, and privileged attacker.
3. Unencrypted data stored in etcd.
4. The complexity of the Kubernetes environment increases the difficulty of using threat modeling applications in Kubernetes environments.
5. Kubernetes introduces additional assets and interactions with applications. This increases the complexity of applications in Kubernetes, increasing the attack surface.

Chapter 4

1. A Role object contains rules consisting of verbs and resources that indicate the operational privileges for resources in a namespace.
2. A RoleBinding object links the Role object in a namespace to a group of subjects (for example, User and ServiceAccount). It is used to grant privileges defined in the Role objects to the subjects.
3. RoleBinding indicates that the privileges the subjects have are effective in the RoleBinding object's namespace. ClusterRoleBinding indicates that the privileges the subjects have are effective in the entire cluster.
4. hostPID, hostNetwork, and hostIPC.
5. Create a network policy for the Pod with an egress rule.

Chapter 5

1. Master components, worker components, and Kubernetes objects.
2. Pod, service/Ingress, api-server, nodes, and namespace.
3. RBAC and network policy.
4. Processes in the Pod can access host the PID namespace, viewing all the processes running in the worker node.

   kind: NetworkPolicy

   metadata:

     name: allow-good

   spec:

     podSelector:

       matchLabels:

         app: web

     policyTypes:

     - Ingress

     ingress:

     - from:

       - namespaceSelector:

           matchLabels:

             from: <allowed_label>

Chapter 6

1. Token-based authentication enables static tokens to be used to identify the origin of requests in the cluster. Static tokens cannot be updated without restarting the API server and so should not be used.
2. The NodeRestriction admission controller ensures that a kubelet can only modify the node and Pod objects for the node that it is running on.
3. Pass --encryption-provider-config to the API server to ensure data is encrypted at rest in etcd.
4. Security vulnerabilities in dnsmasq, performance issues in SkyDNS, and a single container instead of three for kube-dns to provide the same functionality.
5. You can use kube-bench on an EKS cluster as follows:

   $ git clone : https://github.com/aquasecurity/kube-bench
$ kubectl apply -f job-eks.yaml

Chapter 7

1. Static tokens and basic authentication should not be used in production clusters. These modules use static credentials, which require a restart of the API server to be updated.
2. Cluster administrators can use the user impersonation privileges to test the permissions granted to a new user. Using kubectl, cluster administrators can use the --as --as-group flags to run requests as a different user.
3. Node and RBAC are enabled by default in Kubernetes. These should be used. If the cluster uses a remote API for authorization, Webhook mode should be used instead.
4. The EventRateLimit admission controller specifies the maximum limit for requests that can be serviced by the API server. On the other hand, LimitRanger ensures that Kubernetes objects adhere to the resource limits specified by the LimitRange object.
5. The rego policy to deny the creation of an Ingress with the test.example endpoint is as follows:

   package kubernetes.admission

   import data.kubernetes.namespaces

   operations = {"CREATE", "UPDATE"}

   deny[msg] {

       input.request.kind.kind == "Ingress"

       operations[input.request.operation]

       host := input.request.object.spec.rules[_].host

       host == "test.example"

       msg := sprintf("invalid ingress host %q", [host])

   }

Chapter 8

1. Defines a command to ask Docker Engine to check the health status of the container periodically.
2. The COPY instruction can only copy files from build machine to the filesystem of the image, while the ADD instruction can not only copy files from localhost but also retrieve files from remote URLs to the filesystem of the image. Using ADD may introduce the risk of adding malicious files from the internet to the image.
3. CAP_NET_BIND_SERVICE.
4. With the runAsNonRoot setting set to true, kubelet will block the container from starting if run as root user.
5. Create a role with privilege, use the PodSecurityPolicy object, and create a rolebinding object to assign the role to the service account that is used by the workload.

Chapter 9

1. Docker history <image name>.
2. 7-8.9.
3. anchore-cli image add <image name>.
4. anchore-cli image vuln <image name> all.
5. anchore-cli evaluate check <image digets> --tag <image full tag>.
6. It helps identify images with latest publicly known vulnerabilities.

Chapter 10

1. Resource requests specify what a Kubernetes object is guaranteed to get, whereas limits specify the maximum resources a Kubernetes object can use.
2. The resource quota that limits memory to 500 mi is as follows:

   apiVersion: v1

   kind: ResourceQuota

   metadata:

       name: pods-medium

   spec:

       hard:

         memory: 500Mi

3. LimitRanger is an admission controller that enforces LimitRanges. LimitRange defines constraints on a Kubernetes resources. A limit range can be applied to a Pod, container, or persistantvolumeclaim. Namespace resource quotas are similar to LimitRange, but are enforced for the entire namespace.
4. Service account tokens.
5. Prometheus and Grafana.

Chapter 11

1. The secret data will be recorded in the Kubernetes audit log.
2. --master-zones.
3. Sync the updated secret to the Pod's mounted volume.
4. System calls and Kubernetes audit events.
5. proc.name.
6. Checkpoint a running container, which can be restored later in a sandboxed environment.
7. Troubleshooting and security investigation.

Chapter 12

1. Dashboard is used without authentication enabled.
2. Do not run Dashboard, or enable authentication for Dashboard.
3. No. It could be a crypto mining attack, but it could also be caused by some other things, such as application errors.
4. The crypto mining binary uses the HTTP or HTTPS protocol to connect to the mining pool server instead of stratum.
5. Kubernetes cluster provisioning, build, deployment, and runtime.

Chapter 13

1. Cluster administrators keep track of CVE IDs to ensure that the Kubernetes cluster is not vulnerable to a publicly known issue. Security researchers study the references section to understand the technical details of the issue to develop mitigations for a CVE. Lastly, attackers study the references section to find unpatched variations or use similar techniques to discover issues in other parts of the code.
2. Client-side issues often lead to data exfiltration or code execution on the client side. Build machines or machines of cluster administrators often contain sensitive data, and an attack on such machines can have a significant economic impact on the organization.
3. DoS issues on api-server can lead to disruption of the availability of the entire cluster.
4. Unauthenticated DoS issues are more severe than authenticated DoS issues. Ideally, unauthenticated users should not be able to communicate with api-server. If an unauthenticated user is able to send requests and cause a DoS issue for api-server, it is worse than an authenticated user. Authenticated DoS requests are also very severe since a misconfiguration in the cluster can allow an unauthenticated user to escalate privileges and become an authenticated user.
5. Security advisories and announcements by Kubernetes are a great way to learn about any new publicly known vulnerabilities. These announcements and advisories are fairly noisy, and administrators can easily miss an important issue. Running kube-hunter regularly helps cluster admins identify any publicly known issues that administrators might have missed.