### Overview
Security is a multifaceted topic, especially in a distributed system like Kubernetes. Here, we'll cover key security concepts relevant to Kubernetes, focusing on authentication, authorization, admission control, pod security, and network policies.
### Accessing the API
To perform any action in a Kubernetes cluster, you need to access the API, which involves three main steps:
1. **Authentication**: Verifying the identity of the user or service.
2. **Authorization**: Checking if the authenticated identity has permission to perform the requested action.
3. **Admission Controllers**: Validating and potentially modifying the request before it is executed.
This flow is illustrated by the diagram below, retrieved from the Kubernetes website:
#### Authentication
Authentication in Kubernetes can be done using various methods, including:
- **Certificates**: x509 client certificates.
- **Tokens**: Static tokens, bearer tokens, or bootstrap tokens.
- **Basic Authentication**: Username and password.
- **Service Accounts**: For processes accessing the API.
Advanced mechanisms include:
- **Webhooks**: For verifying bearer tokens.
- **OpenID Connect (OIDC)**: For integration with external identity providers.
Example configuration options for `kube-apiserver`:
```sh
--basic-auth-file=path/to/basic/auth/file
--oidc-issuer-url=https://issuer.url
--token-auth-file=path/to/token/auth/file
--authorization-webhook-config-file=path/to/webhook/config
```
The authenticator modules are tried in a specific order until one succeeds. If none succeed, the request is denied with a 401 Unauthorized response.
#### Authorization
Once authenticated, the request must be authorized. Kubernetes supports several authorization modes, including:
- **Role-Based Access Control (RBAC)**: Defines roles and role bindings to control access.
- **Webhook**: Uses an external service to authorize requests.
- **Node**: Authorizes requests from kubelets.
Example `kube-apiserver` configuration for authorization modes:
```sh
--authorization-mode=RBAC,Webhook
```
**RBAC** involves creating roles and role bindings:
- **Roles**: Define permissions within a namespace.
- **ClusterRoles**: Define permissions cluster-wide.
- **RoleBindings**: Bind a role to a user or group within a namespace.
- **ClusterRoleBindings**: Bind a cluster role to a user or group cluster-wide.
Example RBAC configuration:
```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]
```
```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
- kind: User
name: jane
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
```
### Admission Controllers
Admission controllers are plugins that intercept API requests after authentication and authorization but before the object is persisted. They can modify or reject requests.
Example configuration to enable or disable admission controllers:
```sh
--enable-admission-plugins=Initializers,NamespaceLifecycle,LimitRanger
--disable-admission-plugins=PodNodeSelector
```
Controllers like `ResourceQuota` ensure resource usage does not exceed predefined limits, while `PodSecurityPolicy` governs pod security configurations.
### Security Contexts
Pods and containers can have specific security constraints to limit their privileges. These are defined using security contexts.
Example pod security context:
```yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
securityContext:
runAsNonRoot: true
containers:
- image: nginx
name: nginx
```
This configuration ensures the container does not run as the root user.
### Pod Security Policies
Pod Security Policies (PSP) are cluster-level rules that control what pods can do, such as user IDs, privileges, and namespaces.
Example PSP:
```yaml
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: restricted
spec:
seLinux:
rule: RunAsAny
supplementalGroups:
rule: RunAsAny
runAsUser:
rule: MustRunAsNonRoot
fsGroup:
rule: RunAsAny
```
**Note**: PSPs are deprecated and will be removed in Kubernetes 1.25, replaced by Pod Security Admission.
### Network Policies
Network policies control the flow of traffic between pods. By default, all traffic is allowed.
Example NetworkPolicy:
```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: ingress-egress-policy
namespace: default
spec:
podSelector:
matchLabels:
role: db
policyTypes:
- Ingress
- Egress
ingress:
- from:
- ipBlock:
cidr: 172.17.0.0/16
except:
- 172.17.1.0/24
- namespaceSelector:
matchLabels:
project: myproject
- podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 6379
egress:
- to:
- ipBlock:
cidr: 10.0.0.0/24
ports:
- protocol: TCP
port: 5978
```
### Conclusion
Securing a Kubernetes cluster involves multiple layers, from API access control to pod-level security and network policies. Proper configuration and continuous monitoring are essential to maintain a secure environment. Integrating security best practices into the CI/CD pipeline ensures that security is not an afterthought but a core part of the development and deployment process.
Continue: [[15-High Availability - HA]]