k8s-Security
Kubernetes Security Primitives
Secure Hosts
- Password based authentication disabled
- SSH Key based authentication
Authentication
Who can access?
- Files – Username and Passwords
- Files – Username and Tokens
- Certificates
- External Authentication providers - LDAP
- Service Accounts
What can they do?
- RBAC Authorization
- ABAC Authorization
- Node Authorization
- Webhook Mode
TLS Certificates
All communication with the cluster, between the various components such as the ETCD cluster, kube controller manager, scheduler, api server, as well as those running on the worker nodes such as the kubelet and and kubeproxy is secured using TLS Encryption.
Network Policies
TLS Certifications
SYMMETRIC ENCRYPTION
It is a secure way of encryption but since it uses the same key to encrypt and decrypt the data and since the key has to be exchanged between the sender and the receiver there is a risk of a hacker gaining access to the key and decrypting the data.
ASYMMETRIC ENCRYPTION
If you encrypt or lock the data with your lock,you can only open it with the associated key.
opensssl
TSL in k8s
certificates with public keys are named
crt
orpem
extension.Example:
server.crt
,server.pem
for server certificates orclient.crt
orclient.pem
for client certificates.private keys are usually with extension
.key
, or with a–key
in filename.For example
server.key
orserver-key.pem
.
Communication between all the components within the kubernetes cluster need to be secured.
All the various services within the cluster to use server certificates and all clients to use client certificates to verify they are who they say they are.
Server Certificates for Servers
- API server: exposes an HTTPS service that other components as well as external users use to manage the Kubernetes cluster.(
apiserver.crt
,apiserver.key
) - ETCD server: stores all information about the cluster so it requires a pair of certificate and key for itself.(
etcdserver.crt
,etcdserver.key
) - kubelet server: expose an HTTPs API endpoint that the Kubeapi server talks to and to interact with the worker nodes.(
kubelet.crt
,kubelet.key
)
admin user(client for kube-api server): access the kube-api server through Kubectl or Rest API. The admin user requires a certificate and key pair to authenticate the kube-api server.
scheduler(client for kube-api server): talks to the kube-api server to look for pods that require scheduling and then get kube-api server to schedule the pods on the right worker nodes.So the scheduler needs to validate its identity using a client TLS certificate.
kube-controller manager (client for kube-api server):is another client that accesses the kube-api server
kube-proxy(client for kube-api server): requires a client certificate to authenticate to the kube-api server.
kube-api server(client for etcd server & kubelet server):
The kube-api server is the only server that talks to the ETCD server.. The kubeapi server can use the same keys that used earlier for serving its own API service.(You can also generate a new pair of key)
The kube-api server also talks to the kubelet server on each of the individual nodes. That’s how it monitors the worker nodes.
Summary
TLS in Kubernetes -Certificate Creation
SKIP
View Certificate Details
TODO: add lesson note.
Practice
Identify the certificate file used for the
kube-api server
Look for kubelet-client-key option in the file
/etc/kubernetes/manifests/kube-apiserver.yaml
Result:
--tls-cert-file=/etc/kubernetes/pki/apiserver.crt
Identify the Certificate file used to authenticate
kube-apiserver
as a client toETCD
Server--etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt
Identify the key used to authenticate
kubeapi-server
to thekubelet
server--kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key
Identify the ETCD Server Certificate used to host ETCD server
Look for cert file option in the file
/etc/kubernetes/manifests/etcd.yaml
Result:
--cert-file=/etc/kubernetes/pki/etcd/server.crt
Identify the ETCD Server CA Root Certificate used to serve ETCD Server
ETCD can have its own CA. So this may be a different CA certificate than the one used by kube-api server.
Result
--peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
What is the Common Name (CN) configured on the Kube API Server Certificate?
OpenSSL Syntax:
openssl x509 -in file-path.crt -text -noout
Run the command :
openssl x509 -in /etc/kubernetes/pki/apiserver.crt -text
Result:
Subject: CN = kube-apiserver
What is the name of the CA who issued the Kube API Server Certificate?
Run the command:
openssl x509 -in /etc/kubernetes/pki/apiserver.crt -text
Result:
Issuer: CN = kubernetes
Which of the below alternate names is not configured on the Kube API Server Certificate?
1
2Subject Alternative Name:
DNS:controlplane, DNS:kubernetes, DNS:kubernetes.default, DNS:kubernetes.default.svc, DNS:kubernetes.default.svc.cluster.local, IP Address:10.96.0.1, IPAddress:172.17.0.21What is the Common Name (CN) configured on the ETCD Server certificate?
Run the command :
openssl x509 -in /etc/kubernetes/pki/etcd/server.crt -text
and look for Subject CN.Result:
Subject: CN = controlplane
Certificates API
With the Certificates API, you can send a Certificate Signing Request directly to kubernetes through an API call.
First a user creates a key. Then generates a certificate signing request using the key with name in it.
1
openssl genrsa -out jane.key 2048
Second,send the request to administrator.
1
openssl req -new -key jane.key -subj "/CN=jane" -out jane.csr
Third,The administrator takes the key(encoded by base64) and creates a certificate signing request object by using a manifest.
Check all certificate signing requests.
1
kubectl get csr
approve the certificate
1
kubectl certificate approve jane
View the certificate in yaml format and decode it.
1
kubectl get csr jane -o yaml
All the certificate related operations are carried out by the controller manager.
If anyone has to sign certificates, they need the CA servers
root certificate
and private key
.
The controller manager service configuration has two options where you can specify this