Section 6 : Security
K8s security primitives
● All hosts / nodes should be secured :-
○ Password based authentication disabled —> Only ssh-keys used.
○ Root login disabled.
● Security primitives are authentication / Who can access ? and
authorization / What they do ?
Authentication
○ Who can access ?
○ Access to k8s api server can be controlled through the following
mechanisms :-
◆ Files
– Usernames and passwords.
– Usernames and tokens.
◆ Certificates
◆ External authentication mechanisms
– LDAP
◆ Service accounts
Authorization
○ What can they do ?
○ Admins and users’ actions can be restricted using :-
❑ RBAC Authorization
◆ RBAC : Role Based Authentication.
❑ ABAC Authorization
◆ ABAC : Attribute Based Authentication.
❑ Node Authorization
❑ Webhook Mode
● Access to all components in a k8s is protected with TLS certificates.
● All objects in a k8s cluster should be able to access each other with
names.
Authentication
● Authentication mechanism used to authenticate a user to Kube-
apiserver is using TLS certificates.
Service accounts
● Is an account used by an application to interact with the k8s cluster.
Examples :-
○ A monitoring application like prometheus uses a service account
to pull the k8s api for performance metrics.
○ An automation to like jenkins uses a service account to deploy
apps on the cluster.
● To create a service account use :-
○ Command : k create serviceaccount <name>
○ View service accounts : k get serviceaccount
● When a service account is created it also create a token automatically.
– The token is what must be used to by the external application
while authenticating to the k8s API.
– The token is stored as a secret object. Meaning in base64.
– The token is usually named dashboard-token-sa-kbbdm.
– After a service account object is created it generates a token for
the service account.
◆ It then creates a secret object and stores that token inside the
secret object.
◆ The secret object is linked to the service account.
◆ To view token, view the secret object by running :-
– Command : k describe secret dashboard-token-sa-
kbbdm. kbbdm is just a random string chosen by k8s.
○ You create a new service account, assign the right permissions
using RBAC, export your service account token and use it to
configure access for third party applications to authenticate to the
Kubernetes API.
○ If the third party app is hosted inside the cluster, you can mount
the token using volume to make it simple for the pods to
○
authenticate themselves with to the Kubernetes API.
● For every namespace in k8s, a service account named default is
automatically created.
○ Whenever a pod is created in that namespace, the default service
account with its token are automatically mounted to that pod as
volume mount.
○ However, the default Kubernetes API is restrict to making basics
calls to the Kubernetes API.
○ If you want you use a custom service account by modifying the
pod definition file and adding the property :
◆ serviceAccountName: <name>
◆ Under the spec section.
○ NOTE : You cannot edit a service account for the existing pod.
First delete the pod, edit the service account and recreate a new
one. In case of a deployment, you are able to change the service
account since pods will be recreated automatically after the
change.
○ Kubernetes auto-mounts the default service account to the pods.
If you would not like this set the property :
◆ automountServiceAccountToken : false
◆ Under the spec section.
Service accounts update from v1.22 / v1.24
v1.22
◆ The tokens from previous versions presented some risks as
expressed in the KEP 1205 - Bound Service Account Tokens.
– SECURITY : are not time bound. In other words, they had
no expiry date.
– SECURITY : are not audience bound, any recipient of the
JWT can masquerade as the presenter to anyone else.
– SECURITY : the pre-current model of storing the token as
a secret and delivering it to nodes results in a broad based
attack to the control-plane. Giving permissions to service
accounts means that any component in k8s cluster that
can see the service accounts secrets is at least as
powerful as the component.
– SCALABILITY : JWTs require a K8s secret object per
service account.
◆ In v1.22 the TokenRequestAPI was introduced as part of the
KEP-1205 that aimed to introduce a mechanism for
provisioning K8s service account tokens that are more secure
and scalable via an API.
◆ Token generated by the TokenRequestAPI are time bound,
audience-bound and object bound making the more secure.
◆ From the on when a pod is created it no longer relies on the
service account secret token. Instead, a token with a defined
life time is generated through the TokenRequestAPI by the
service account admission controller and this token mounted
as a projected volume into the pod which communicated with
the token controller API and get a token for the pod.
v1.24
◆ In v1.24 another enhancement was made as part of KEP 2799 -
Reduction of secret based service account tokens.
◆ From v1.24 onwards, when you create a service account it no
longer automatically creates a secret token.
– To generate a token for the service account run :
◆ Command : k create token <service-account-name>
◆ To create a token for the service account if you need
one.
◆ It you attempt to decode the decode the token from
jwt.io, you’ll see that it now has a expiry period of one
hour from the time you run the command by default if
not specified. You can pass in option to increase this
time.
Network policies
● A network policy is an object in k8s namespace, which is linked to one
or more pods to implement the rules defined in it on the pods.
● An example of a network policy can be :-
○ Only allow ingress traffic from the API Pod to the DB pod on port
3306.
◆ This policy blocks all other incoming traffic on other ports.
◆ Labels and selectors are used to link a network policy to a pod.
◆ Pod Labels :-
– Labels:
role : db
◆ Selectors in the network policy manifest file include
◆ PodSelector :-
– PodSelector:
matchLabels:
role : db
◆ NamespaceSelector :-
– namespaceSelector:
matchLabels:
name: prod
● NOTES :
○ Ingress or egress isolation comes into effect if you defined it in the
policyTypes property.
◆ If you only define ingress type, egress traffic will be unaffected
and vice versa.
◆ If you only define ingress, you don’t need a separate rule for
egress of the results traffic.
– Once you allow incoming traffic, the response is allowed
automatically without having to configure a separate rule.
○ Network policies are enforced by the networking solution
implemented in the k8s cluster.
◆ Not all network solution support network policies. Ones that
support it include :-
– Kube-router
– Calico
– Romana
– Weave-net
