Kubernetes deployments can inadvertently introduce security risks, especially when using high-privilege administrator credentials. A common pitfall is sharing the administrator kubeconfig with CI/CD tools, exposing your entire cluster to potential compromise. To mitigate this risk, adopt the principle of least privilege by creating dedicated service accounts tailored for deployment tasks. This article demonstrates how to create a service account, role, and role binding within the mycloud namespace, and generate a secure kubeconfig for deployment purposes.
We'll begin by defining a service account named deployer, along with a corresponding Role and RoleBinding that grant only the necessary permissions for deployments within the mycloud namespace. Create a file named deployer.yaml with the following content:
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: deployer # Choose a descriptive name
namespace: mycloud
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: deployer-role
namespace: mycloud
rules:
- apiGroups: ["", "apps", "extensions", "networking.k8s.io"] # Add necessary API groups
resources: ["deployments", "pods", "services", "ingresses", "persistentvolumeclaims", "configmaps", "secrets"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: deployer-role-binding
namespace: mycloud
subjects:
- kind: ServiceAccount
name: deployer
namespace: mycloud
roleRef:
kind: Role
name: deployer-role
apiGroup: rbac.authorization.k8s.io
---
apiVersion: v1
kind: Secret
metadata:
name: deployer-secret
namespace: mycloud
annotations:
kubernetes.io/service-account.name: deployer
type: kubernetes.io/service-account-token
Note: For enhanced security, newer Kubernetes versions do not automatically create service account tokens. We explicitly define the secret to generate the token.
Then we create the resources:
kubectl apply -f deployer.yaml
To enable your CI/CD pipeline to authenticate as the deployer service account, generate a dedicated kubeconfig. The following script retrieves the necessary data from your cluster and creates a sa.kubeconfig file:
#!/bin/bash
# The name of the secret containing the service account token goes here
name=deployer-secret
server=$(kubectl config view -o jsonpath='{.clusters[0].cluster.server }')
ca=$(kubectl -n mycloud get secret/$name -o jsonpath='{.data.ca\.crt}')
token=$(kubectl -n mycloud get secret/$name -o jsonpath='{.data.token}' | base64 --decode)
namespace=$(kubectl -n mycloud get secret/$name -o jsonpath='{.data.namespace}' | base64 --decode)
cat <<EOF > sa.kubeconfig
apiVersion: v1
kind: Config
clusters:
- name: default-cluster
cluster:
certificate-authority-data: ${ca}
server: ${server}
contexts:
- name: default-context
context:
cluster: default-cluster
namespace: mycloud
user: default-user
current-context: default-context
users:
- name: default-user
user:
token: ${token}
EOF
Verify the configuration by using the generated kubeconfig:
kubectl --kubeconfig=sa.kubeconfig -n mycloud get pods
This command confirms that the service account has the correct permissions within the mycloud namespace.
Implementing the principle of least privilege with dedicated service accounts significantly strengthens your Kubernetes security posture. By restricting permissions and using a dedicated kubeconfig, you minimize the impact of potential credential leaks and protect your cluster from unauthorized access. This practice is essential for maintaining a secure and robust Kubernetes environment.