Scribd
Upload
8 views6 pages

Section 6: Security

K8s uses authentication and authorization to control access. Authentication controls who can access the API server through files, certificates, or external mechanisms like LDAP. Authorization controls what actions users can take through RBAC and ABAC. Service accounts are used by applications to authenticate to the cluster and generate tokens stored as secrets. Network policies use labels and selectors to implement ingress/egress rules for pods.

Uploaded by

benjaminruhinda
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
8 views6 pages

Section 6: Security

K8s uses authentication and authorization to control access. Authentication controls who can access the API server through files, certificates, or external mechanisms like LDAP. Authorization controls what actions users can take through RBAC and ABAC. Service accounts are used by applications to authenticate to the cluster and generate tokens stored as secrets. Network policies use labels and selectors to implement ingress/egress rules for pods.

Uploaded by

benjaminruhinda
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

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

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy