Kubernetes and Cloud Native Security Associate (KCSA)

Overview

Like the KCNA exam, the KCSA exam is an entry-level certification that focuses on Kubernetes and Cloud Native security fundamentals. This multiple-choice exam tests your understanding of essential security concepts including Kubernetes security architecture, network policies, and security best practices.

Read through the Kubernetes and Cloud Native Security Associate (KCSA) page for Domain and Competency details and information on how to register for the exam.

I also published a KCSA study guide that you may find helpful.

Some of the topics that you should be familiar with are:

4Cs of Cloud Native Security
Kubernetes cluster component security
Kubernetes security fundamentals
Platform security
Compliance and security frameworks

4Cs of Cloud Native Security

The 4Cs of Cloud Native Security is a framework developed by the Kubernetes community to help organizations understand the multiple layers where security must be addressed in cloud native environments. Each layer builds upon the previous one, creating a defense-in-depth security posture.

Code Security

Security at the application code level, including both your custom code and dependencies.

Key considerations:

Software Composition Analysis: Identify vulnerabilities in dependencies using tools like Dependabot, Snyk, or OWASP Dependency-Check
Static Application Security Testing (SAST): Analyze source code for security issues before deployment
Dynamic Application Security Testing (DAST): Test running applications for vulnerabilities
Secure coding practices: Follow principles like input validation, proper error handling, and least privilege

Example tools: SonarQube, GitHub Advanced Security, Checkmarx

Container Security

Security of container images, their contents, build process, and runtime behavior.

Key considerations:

Minimal base images: Use distroless or minimal images to reduce attack surface
Image scanning: Scan container images for vulnerabilities before deployment
No root: Run containers as non-root users whenever possible
Immutability: Treat containers as immutable and avoid runtime changes
Signed images: Use tools like Cosign to sign and verify container images

Example tools: Trivy, Clair, Docker Scout, Notary

Cluster Security

Security of the Kubernetes platform itself, including all components and configurations.

Key considerations:

Authentication & authorization: Implement strong RBAC policies
Network policies: Restrict pod-to-pod communication
Secrets management: Securely store and manage secrets
CIS benchmarks: Follow Kubernetes security benchmarks
Pod security standards: Implement appropriate pod security standards
Audit logging: Enable and monitor audit logs

Example tools: Kyverno, OPA Gatekeeper, Falco, kubesec

Cloud Security

Security of the underlying infrastructure provided by the cloud platform.

Key considerations:

IAM configuration: Implement proper identity and access management
Network security: Configure VPCs, security groups, and firewalls
Encryption: Enable encryption at rest and in transit
Compliance: Adhere to relevant compliance frameworks (SOC2, PCI-DSS, etc.)
Resource policies: Implement resource policies to prevent misconfigurations

Example tools: AWS Security Hub, Azure Security Center, Google Security Command Center

Applying the 4Cs Model

To effectively use the 4Cs model:

Assess each layer for security gaps independently
Prioritize issues based on risk and potential impact
Implement security controls at each layer
Monitor continuously using appropriate tools for each layer

Remember that security issues in lower layers can undermine security at higher layers. For example, even the most secure application code can be compromised if running in a container.

Reference: https://kubernetes.io/docs/concepts/security/

Kubernetes cluster component security

Kubernetes is a complex system with many components. Each component has its own security considerations. Here are some of the key components and their security considerations:

kube-apiserver: The API server is the front-end for the Kubernetes control plane. It is responsible for serving the Kubernetes API and handling requests from clients. The API server should be secured using TLS and authentication.
kubelet: The kubelet is the primary "node agent" that runs on each node in the cluster. It is responsible for managing the state of the node and the containers running on it. It also communicates with the API server. Therefore it is important to disable anonymous authentication and use either webhook or node authorization mode to secure access to the kubelet's HTTPS endpoint.
etcd: The etcd database is used to store the state of the Kubernetes cluster. It is important to secure etcd using TLS and authentication. It is also important to restrict access to etcd to only the components that need it. You can also implement encryption at rest for etcd data.

Reference: https://kubernetes.io/docs/concepts/security/cluster-components/

Kubernetes security fundamentals

Let's practice with some exercises to help familiarize yourself with the concepts.

Managing secrets

Kubernetes Secrets are a way to store sensitive information. Secrets are stored in etcd and are base64 encoded (not encrypted); which is a key consideration when using them. Anyone with access to the etcd database can read the secrets. Therefore, it is important to use encryption at rest for etcd data.

You can use kubectl to create a secret from a file or literal value.

Create a secret from a file.

echo "mysupersecretpassword" > /tmp/mysecret
kubectl create secret generic my-secret-from-file --from-file=/tmp/mysecret

Or to create a secret from a literal value.

kubectl create secret generic my-secret-from-literals --from-literal=username=admin --from-literal=password=mysupersecretpassword

You can also create a secret from an environment variable file.

echo "password=mysupersecretpassword" > /tmp/myenvfile
kubectl create secret generic my-secret-from-env --from-env-file=/tmp/myenvfile

To view the secret, you can use the following command.

kubectl get secret my-secret-from-env -o json

Remember the secret data is base64 encoded. To decode the secret, you can use the following command.

kubectl get secret my-secret-from-env -o jsonpath='{.data.password}' | base64 --decode

Reference: https://kubernetes.io/docs/tasks/configmap-secret/managing-secret-using-kubectl/

Securing network traffic

In Kubernetes, all Pods can communicate with each other by default, creating potential security risks. Network Policies is essential for controlling this traffic by specifying how groups of Pods are allowed to communicate. They effectively act as a firewall for Layer 3 and Layer 4 traffic in your Kubernetes cluster.

Let's practice implementing these controls.

Create two nginx deployments and expose them.

kubectl create namespace n287
kubectl create deploy nginx1 --image=nginx --namespace n287
kubectl create deploy nginx2 --image=nginx --namespace n287
kubectl expose deploy nginx1 --port=80 --namespace n287
kubectl expose deploy nginx2 --port=80 --namespace n287

By default, network traffic is wide open within a cluster. So if you exec into nginx1 Pod and try to curl to nginx2, you'll get a 200 response.

POD_NAME=$(kubectl get pod --namespace n287 -l app=nginx1 -o jsonpath='{.items[0].metadata.name}')
kubectl exec -it $POD_NAME --namespace n287 -- curl -IL nginx2

Now let's create a NetworkPolicy that denies all ingress traffic to nginx2.

kubectl apply --namespace n287 -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: n287
spec:
  podSelector:
    matchLabels:
      app: nginx2
  policyTypes:
  - Ingress
EOF

Note

The command above uses a combination of kubectl apply and -f - to create a resource from stdin. This is a common pattern used in Kubernetes tutorials and documentation to create declarative resources without creating a separate YAML file but rather using a heredoc.

Now if you try to curl nginx2 from nginx1, you'll get a connection timeout.

kubectl exec -it $POD_NAME --namespace n287 -- curl -IL nginx2 --connect-timeout 1

Create a NetworkPolicy that allows ingress traffic to nginx2 from nginx1.

kubectl apply --namespace n287 -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-nginx1
  namespace: n287
spec:
  podSelector:
    matchLabels:
      app: nginx2
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: nginx1
EOF

Now if you try to curl nginx2 from nginx1, you'll get a 200 response.

For more NetworkPolicy practice, check out the NetworkPolicy Editor by Isovalent for an interactive experience.

Note

NetworkPolicies require a compatible Container Network Interface (CNI) plugin. Not all Kubernetes distributions support NetworkPolicies by default. Common CNI plugins that support NetworkPolicies include Calico, Cilium, and Weave Net.

Platform security

Platform security is the security of the underlying infrastructure that Kubernetes runs on. This includes the operating system, the container runtime, and the cloud provider. Here are some key considerations for platform security:

Use a minimal base image for your container images. This reduces the attack surface and makes it easier to keep your images up to date.
Use a container runtime that supports security features like seccomp, AppArmor, and SELinux. These features can help to restrict the capabilities of your containers and reduce the risk of a security breach.
Use a runtime security tool like Falco to monitor your containers for suspicious activity. Falco can help to detect things like privilege escalation, file access, and network activity that isn't allowed by your security policies.
Use a cloud provider that has strong security features and compliance certifications. This can help to ensure that your applications are running in a secure environment.
Implement admission control policies to enforce security policies at the time of Pod creation. This can help to ensure that only compliant Pods are allowed to run in your cluster.

Reference: https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/

Compliance and security frameworks

Compliance and security frameworks are a set of guidelines and best practices that help organizations to secure their Kubernetes clusters.

Some of the most popular frameworks include:

CIS Kubernetes Benchmark: A set of best practices for securing Kubernetes clusters. The benchmark includes recommendations for securing the API server, etcd, kubelet, and other components.
NIST Cybersecurity Framework: A set of guidelines for managing cybersecurity risk. The framework includes recommendations for identifying, protecting, detecting, responding to, and recovering from cybersecurity incidents.
PCI DSS: A set of security standards for organizations that handle credit card information. The standards include requirements for securing the network, applications, and data.
HIPAA: A set of regulations for protecting the privacy and security of health information. The regulations include requirements for securing the network, applications, and data.

Additional Resources

Be sure to read through the following for more information on security best practices: