### Layers Cloud native security consists of 4 layers. Each part resides in its parent: #### Cloud/Co-Lo/Corporate Datacenter Use datacenters that don't have a SPOF in their system. e.g. they use different power sources for their racks. #### Cluster The configuration of the cluster and its default applications should abide with the security patterns. #### Container Containers should be checked for unnecessary port exposing. #### Code Different logic for security compliance like proper authentication, query injections and proper redirection should be checked. ### RBAC RBAC (role-based access control) is the default authorisation method used in Kubernetes. ![[Pasted image 20250213085426.png|kubernets-rbac-objects]] #### Role (Binding) ![[Pasted image 20250213090011.png|kubernetes-rolebinding]] In a *Role*, we describe what access is given. An access contains a *resource* and a *verb*. e.g. resource=`service`, verb=`GET`. A resource/verb object can contain a list. e.g. verb=`GET,LIST`. In a *Role Binding*, the respective Role is attached to a subject. > [!note] > *Role* and *RoleBinding* are defined **within a [[Objects#Namespaces|namespace]]**. On the other hand, *Cluster Role* and *Cluster Role Binding* are defined within the whole Cluster. Also, a RoleBinding should be selected in *Cluster Role Binding*. ![[Pasted image 20250213090627.png]] For example, a user can be defined for read-only purposes for the entire Cluster. #### Service Account A *Service Account* is a type of non-human account that, in Kubernetes, provides a distinct identity in a Kubernetes cluster. Application Pods, system components, and entities inside and outside the cluster can use a specific ServiceAccount's credentials to identify as that ServiceAccount Instead of making a user, a service account alongside with a token can be created for login purposes.