28 ‐ Kubernetes Security - CloudScope/DevOpsWithCloudScope GitHub Wiki

Type:

A. Client Certificate

B. Service Account Token

C. OpenID Connect

Run the following command to generate a private key:

openssl genrsa -out dev-user.key 2048

Use the private key to generate a CSR. Replace dev-user with the desired CN (Common Name) and O (Organization) as appropriate for your Kubernetes setup:

openssl req -new -key dev-user.key -out dev-user.csr -subj "/CN=dev-user/O=dev-group"

• CN (Common Name): The username for the certificate (e.g., dev-user).
• O (Organization): The group the user belongs to (e.g., dev-group).

We can use below command for generate private key and CSR both.

openssl req -new -newkey rsa:2048 -nodes -keyout dev-user.key -out dev-user.csr -subj "/C=US/ST=CA/O=Organaization/OU=IT/CN=dev-user"

The Kubernetes CA certificate and key are typically located in /etc/kubernetes/pki/ or a similar directory on your cluster's control plane node. Use these files to sign the CSR.

openssl x509 -req -in dev-user.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out dev-user.crt -days 365 -extensions v3_req

• Replace /etc/kubernetes/pki/ca.crt and /etc/kubernetes/pki/ca.key with the actual paths to your Kubernetes CA certificate and key.
• -days 365 specifies the validity period of the certificate.

Also we can use kubectl for signing CSR.

CSR_CONTENT=$(cat dev-user.csr | base64	tr --d '\n')

vi csr.yaml

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: dev-user-csr
spec:
  request: ${CSR_CONTENT} //Replace with CSR_CONTENT
  signerName: kubernetes.io/kube-apiserver-client
  usages:
  - client auth

kubectl apply -f csr.yaml

kubectl certificate approve dev-user-csr // This will approve the CSR

Check the details of the generated certificate to confirm:

openssl x509 -in dev-user.crt -text -noout

if we are using kubectl to signing CSR, below command to get crt.

kubectl get csr dev-user-csr -o jsonpath=’{.status.certificate}’ | base64 -–decode > dev-user.crt

To use the generated certificate with kubectl, create or update a kubeconfig file. Add the dev-user credentials:

kubectl config set-credentials dev-user --client-certificate=dev-user.crt --client-key=dev-user.key

kubectl config set-context dev-context --cluster=<CLUSTER_NAME> --user=dev-user

kubectl config use-context dev-context

Replace <CLUSTER_NAME> with your cluster's name as specified in your kubeconfig.

• Define a set of permissions (rules) to access specific resources within a namespace.
• Control access to Kubernetes objects like Pods, ConfigMaps, and Secrets.
• Permissions are granted through verbs like get, list, create, update, delete.

• Bind a Role to a user, group, or service account.
• Specify who can use the permissions defined in the Role.

A Role that allows listing and viewing Pods in a namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev-namespace
  name: pod-viewer
rules:
- apiGroups: [""]  # "" refers to core API group
  resources: ["pods"]
  verbs: ["get", "list"]

Bind the pod-viewer Role to a user or service account:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-viewer-binding
  namespace: dev-namespace
subjects:
- kind: User
  name: dev-user  # User or service account name
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-viewer
  apiGroup: rbac.authorization.k8s.io

A ClusterRole that allows listing all namespaces:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: namespace-list-viewer
rules:
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["get", "list"]

Bind the namespace-list-viewer ClusterRole to a user:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: namespace-list-viewer-binding
subjects:
- kind: User
  name: dev-user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: namespace-list-viewer
  apiGroup: rbac.authorization.k8s.io

Define the actions allowed on resources:

• Common verbs: get, list, create, update, delete, watch.

Objects managed by Kubernetes:

• Core resources: pods, services, configmaps, secrets.
• API groups: Extend Kubernetes with custom resources.

The entities that receive permissions:

• User: Refers to a human user.
• Group: A collection of users.
• ServiceAccount: Represents applications or pods.

Links a Role or ClusterRole to a RoleBinding or ClusterRoleBinding:

• Specifies the kind (Role or ClusterRole), name, and API group.

1. Least Privilege: Grant only the permissions needed for a task.
2. Namespace Isolation: Use Roles and RoleBindings for namespace-specific access.
3. Cluster-Wide Access: Use ClusterRoles and ClusterRoleBindings only when necessary.
4. Audit Permissions: Regularly review RoleBindings and ClusterRoleBindings.
5. Service Accounts: Use service accounts for applications instead of granting user access.

• View Permissions: Check what a user or service account can access:

  kubectl auth can-i <verb> <resource> --namespace=<namespace>

  Example:

  kubectl auth can-i list pods --namespace=dev-namespace

• Inspect Roles and RoleBindings:

  kubectl get roles -n <namespace>
  kubectl describe rolebinding <name> -n <namespace>

• Read-Only Access: Allow developers to view resources without making changes.
• Namespace-Specific Admins: Grant full access to resources within a specific namespace.
• Cluster-Wide Roles: Provide cluster administrators with permissions to manage nodes, namespaces, or cluster-wide policies.