In this section:
- ServiceAccount - Functional ID inside the Pod
- Role - Specify which verbs can be performed on which resources in a namespace
- RoleBinding - Bind roles to specific users, groups, or ServiceAccounts in a namespace
- ClusterRole - Specify which verbs can be performed on which resources in a cluster
- ClusterRoleBinding - Bind roles to specific users, groups, or ServiceAccounts in a cluster
Kubernetes Security - Introduction
- Security in Kubernetes follows the usual Authentication and Authorization approaches
- Authentication - Who You Are?
- Kubernetes has a system for strong workload identity
- All workloads are associated with service accounts, and they have short-lived OpenID-Connect (OIDC) identity-tokens issued by the Kubernetes API
- The Kubernetes API server signs these OIDC tokens, and other workloads can validate tokens through the Kubernetes API server
- OIDC stands for “OpenID Connect”
- It is an authentication protocol which allows the verification of a user identity when a user is trying to access a protected HTTPS end point
- This solves the Authentication part of the puzzel
- Authorization - What You Can Do?
- Authorization is solved via Roles Based Access Control
- Roles Based Access Control is implemented by the following Kubernetes Resource Types:
- Service Account - Who you are
- Role - What you can do
- Rolebinding - Glue Service Account to Role
- Authentication - Who You Are?
Optional - Enable RBAC on Docker Desktop - Optional
Notes
- RBAC seems to work now on Docker Desktop without this modification
- Only execute this section if the RBAC example does not work
kubectl delete clusterrolebinding docker-for-desktop-bindingcat << EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: docker-for-desktop-binding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: system:serviceaccounts:kube-system
EOF Notes:
- Docker Desktop has a
ClusterRoleBindingcalled docker-for-desktop-binding that givescluster-adminprivileges to all ServiceAccounts - This means that any Pod running on Docker Desktop has cluster-admin privileges
Kubernetes Namespace (ns) - Logical isolation for your application
kubectl create namespace ns-bootcamp-sec
kubectl config set-context --current --namespace=ns-bootcamp-secServiceAccount (sa) - Functional ID inside the Pod to connect to the API server
kubernetes.io bookmark: Configure Service Accounts for Pods
cat << EOF | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
name: my-service-account
imagePullSecrets:
- name: my-image-pull-secret
EOFNotes:
- ServiceAccounts are namespace scoped
- A default serviceAccount is automatically created for each namespace
- ServiceAccounts are nothing more than a way for an application to authenticate itself with the Kubernetes API server
- ServiceAccount use JSON Web Tokens (JWT) to authenticate with the Kubernetes API server
- A ServiceAccount can contain a list of imagePullSecrets
- This saves you from having to include the imagePullSecret with each Pod
Role (Role) - specify which verbs can be performed on which resources
cat << EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: my-role
rules:
- apiGroups: [""]
verbs: ["get", "list"]
resources: ["services"]
EOFNotes:
- Roles are namespaced, if the namespace is omitted, the current namespace is used
- Services are resources in the core apiGroup, which has no name - hence the “”
- Getting individual Services by name and listing all of them is allowed
- This rule pertains to services, the plural name must be used
RoleBinding (RoleBinding) - bind roles to specific users, groups, or ServiceAccounts
cat << EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
creationTimestamp: null
name: my-rolebinding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: my-role
subjects:
- kind: ServiceAccount
name: my-service-account
EOFNotes:
- This RoleBinding references the
my-roleRole - And binds it to the
my-service-accountServiceAccount
kubectl auth can-i
kubectl describe role my-roleName: my-role
Labels: <none>
Annotations: <none>
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
services [] [] [get list]kubectl run service-pod --image=nginx --port=80 --labels="tier=web"
kubectl expose pod service-pod --port=8080 --target-port=80 --name=my-service# Check the permission of the service account: my-service-account
kubectl auth can-i --list --as=system:serviceaccount:ns-bootcamp-sec:my-service-accountResources Non-Resource URLs Resource Names Verbs
selfsubjectaccessreviews.authorization.k8s.io [] [] [create]
selfsubjectrulesreviews.authorization.k8s.io [] [] [create]
services [] [] [get list] #👈👈👈
[/.well-known/openid-configuration] [] [get]
[/api/*] [] [get]
[/api] [] [get]
[/apis/*] [] [get]
[/apis] [] [get]
[/healthz] [] [get]
[/healthz] [] [get]
[/livez] [] [get]
[/livez] [] [get]
[/openapi/*] [] [get]
[/openapi] [] [get]
[/openid/v1/jwks] [] [get]
[/readyz] [] [get]
[/readyz] [] [get]
[/version/] [] [get]
[/version/] [] [get]
[/version] [] [get]
[/version] [] [get]# Permitted RBAC Action
kubectl auth can-i get services --as=system:serviceaccount:ns-bootcamp-sec:my-service-accountyes# Illegal RBAC Action
kubectl auth can-i get pods --as=system:serviceaccount:ns-bootcamp-sec:my-service-accountnoClean Up
cd
yes | rm -R ~/ckad/
kubectl delete ns ns-bootcamp-sec
kubectl delete sa my-serviceaccountNext Sample CKAD exercises and solutions
End of Section