This document discusses various security considerations for containerized applications running on Kubernetes, including:
- Scanning container images for vulnerabilities during the build process and signing images.
- Ensuring container images are minimal in size by using smaller base images like Alpine Linux, running as a non-root user, and mounting the filesystem read-only.
- Implementing role-based access control (RBAC) in Kubernetes using roles and role bindings to control access at the namespace and cluster level.
- Auditing Kubernetes API access for security and compliance purposes.
- Managing secrets securely using Kubernetes secrets rather than environment variables or volumes.
2. About Me - Neependra Khare
● Founder and Principal Consultant at CloudYuga
● Authored Introduction to Kubernetes MOOC on Edx for the CNCF, which is
taken by more than 63,000 people worldwide
● CNCF Ambassador
● Certified Kubernetes Administrator
● More than 15 years of IT experience
● Authored Docker Cookbook ISBN: 9781783984862 in 2015
● Ran Docker Meetup in Bangalore for more than 5 years
6. Security Consideration for Application Imgaes
● Image Scanning
● Image Signing
● Audit and Compliance
Base Container Image
Runtime/Libraries
Application
7. Keep the Image size Minimal
FROM node:10/node:10-alpine
EXPOSE 8080
COPY server.js .
CMD node server.js
REPOSITORY TAG IMAGE ID CREATED SIZE
node-app node-10 fcd053e2141e 11 minutes ago 673MB
node-app node-10-alpine b93e5ada9a6f 11 minutes ago 70.6MB
8. Run program as Non-root User
FROM python:3.7-alpine
RUN addgroup -S apprunner
RUN adduser -G apprunner -S apprunner
USER apprunner
COPY . /opt/app
WORKDIR /opt/app
RUN pip install -r requirements.txt --user
EXPOSE 8080
ENTRYPOINT ["python", "hello.py"]
9. Run as Non-root
apiVersion: v1
kind: Pod
metadata:
name: security-context-uid
spec:
securityContext:
runAsUser: 1000
runAsGroup: 1000
volumes:
- name: sec-ctx-vol
emptyDir: {}
containers:
- name: sec-ctx-userid
image: gcr.io/google-samples/node-hello:1.0
10. Mount the File-System in Read-Only
apiVersion: v1
kind: Pod
metadata:
name: security-context-read-only-fs
spec:
securityContext:
runAsUser: 1000
runAsGroup: 1000
volumes:
- name: sec-ctx-vol
emptyDir: {}
containers:
- name: sec-ctx-userid
image: gcr.io/google-samples/node-hello:1.0
securityContext:
readOnlyRootFilesystem: true
12. Linux Capabilities
“Linux divides the supersuer privileges into distinct units,
which we refer as capabilities”
CAP_CHOWN Make arbitrary changes to file UIDs and GIDs
CAP_NET_RAW * Use RAW and PACKET sockets
* bind to any address for transparent proxying.
………...
14. Control Pod-to-Pod Communication via Netwok Policies
Namespace
Kubernetes Cluster
Namespace default
Namespace prod
Pod A
app=cache
Pod B
app=back
Pod X
app=front
Allow when, app=back
namespace == default
15. Control Pod-to-Pod Communication via Netwok Policies
Namespace
Kubernetes Cluster
Namespace default
Namespace prod
Pod A
app=cache
Pod B
app=back
Pod X
app=front
Allow when, app==back
namespace == default
18. Role Based Access Control (RBAC) - Roles
Role
“Applicable to a given namespace
only.”
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: cloudyuga
name: deployment-manager
rules:
- apiGroups: ["", "apps"]
resources: ["deployments", "replicasets", "pods"]
verbs: ["get", "list", "watch", "create", "update"]
ClusterRole
“Applicable Cluster Wide.”
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: deployment-manager-cluster
rules:
- apiGroups: ["", "apps"]
resources: ["deployments", "replicasets", "pods"]
verbs: ["get", "list", "watch", "create", "update"]
19. Role Based Access Control (RBAC) - Role Bindings
RoleBinding
“Applicable to a given namespace
only.”
ClusterRoleBinding
“Applicable Cluster Wide.”
Role
Subjects
- Normal Users
- Service Accounts
- Groups
ClusterRole
Subjects
- Normal Users
- Service Accounts
- Groups
20. Role Based Access Control (RBAC) - Role Bindings
RoleBinding
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: deployment-manager-binding
namespace: cloudyuga
subjects:
- kind: User
name: nkhare
apiGroup: "rbac.authorization.k8s.io"
roleRef:
kind: Role
name: deployment-manager
apiGroup: "rbac.authorization.k8s.io"
ClusterRoleBinding
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: cluster-manager-binding
subjects:
- kind: User
name: nkhare
apiGroup: "rbac.authorization.k8s.io"
roleRef:
kind: ClusterRole
name: deployment-manager-cluster
apiGroup: "rbac.authorization.k8s.io"
21. Auditing
“Kubernetes audit.k8s.io API Group helps us answer following questions”
● what happened?
● when did it happen?
● who initiated it?
● on what did it happen?
● where was it observed?
● from where was it initiated?
● to where was it going?
22. Secret Management
“Secrets are used for passing the credentials like
Passwords, TLS Certificates.”
Types of Secrets
● Generic
● TLS
● Docker Registry