kubectl is the command-line client for Kubernetes. It can inspect a cluster, expose sensitive data, or change live resources, so knowing the commands is useful—but command fluency alone does not secure a cluster. Safer day-to-day work starts with checking which cluster and namespace a command will reach, using the least access needed, and treating manifests and credentials as production inputs.
This guide is for developers and small teams who operate their own workloads or share cluster administration with a provider. Kubernetes distributions and managed services differ, so use the documentation for your cluster version and confirm which control-plane settings your provider manages.
Confirm the target before using kubectl
The active context in your kubeconfig determines the cluster and identity used by a command. Before an operational session, check the selected context and available contexts:
kubectl config current-context
kubectl config get-contexts
For commands that inspect a workload, specify its context and namespace rather than relying on whichever defaults happen to be active:
kubectl get deployments --context "$CTX" --namespace "$NS"
kubectl get pods --context "$CTX" --namespace "$NS"
Replace CTX and NS with the intended context and namespace. Review the target again before any command that creates, changes, or deletes resources. Avoid sharing raw kubeconfig output: it can contain credentials or certificate data, especially when viewed with --raw.
The Kubernetes kubectl reference documents command behavior and options. The kubectl quick reference can help you look up syntax, but check a command's effect and target before running it. kubectl is the client; the kubelet is the node agent that manages Pods on a node. Their roles and security controls are different.
Give people and workloads only the access they need
Kubernetes RBAC grants permissions to users, groups, and service accounts. Prefer namespace-scoped Role and RoleBinding permissions when they are sufficient. Avoid broad wildcards and routine use of cluster-admin; review bindings periodically and remove access that is no longer needed.
Check what your current identity can do with a specific resource and namespace:
kubectl auth can-i get pods --context "$CTX" --namespace "$NS"
kubectl auth can-i create deployments --context "$CTX" --namespace "$NS"
These are checks for the current identity, not a complete security audit. Treat permission to create workloads as sensitive: someone who can create Pods or Deployments may be able to use service accounts or Secrets available in that namespace. Likewise, list and watch access to Secrets can disclose their contents, not just permission to get a named Secret. The Kubernetes RBAC good practices explain these risks and other privilege-escalation paths.
For applications that do not call the Kubernetes API, consider disabling automatic service-account token mounting for their Pods. Grant a workload a service account only when it needs API access, and limit that account to the required resources and verbs. Review the security checklist with the cluster owner, especially when a managed service handles control-plane settings for you.
Protect Secrets instead of treating them as encrypted by default
Kubernetes Secret values are base64-encoded for representation; that encoding is not encryption. By default, Secret data is stored unencrypted in etcd unless encryption at rest is configured. Limit which people and workloads can read Secrets, mount each credential only into the containers that need it, and avoid printing Secret data in command output, logs, support tickets, or shell history.
Ask the cluster administrator or provider whether encryption at rest is enabled, how its keys are managed, and how backups are protected. The Kubernetes documentation covers Secrets and their security limits and encrypting API data at rest. The latter is a control-plane configuration task; application developers should not assume they can enable it from kubectl.
Apply workload security controls
Use the Pod Security Standards as a baseline for restricting privileged containers, host namespaces, and other risky Pod settings. Cluster owners can enforce a suitable policy with Pod Security Admission. Test the policy against the workloads first, since legitimate system components or application requirements may need a narrower exception.
For each application, review its container security context, service account, mounted volumes, and resource requests and limits. Grant elevated privileges or host access only when a documented requirement justifies them. Use trusted image sources and a repeatable update process so teams can identify what is running and apply security fixes.
NetworkPolicies can reduce unnecessary traffic between workloads, but they only take effect when the cluster's network plugin supports enforcement. Start with the flows an application actually needs, then test both inbound and outbound behavior before tightening rules. See the Kubernetes guide to NetworkPolicies for their scope and limitations.
Keep node and control-plane access out of the application workflow
The API server, etcd, and kubelet expose powerful management surfaces. Keep access restricted to trusted networks and identities, and rely on the managed-service provider's security guidance where it operates those components. Do not expose kubelet endpoints publicly or grant broad permissions to the nodes/proxy subresource: Kubernetes warns that even get access to that subresource can allow commands to be executed in containers on the node.
The current Kubernetes kubelet authentication and authorization guide describes the available controls and the risks of permissive defaults. Cluster owners should also decide what API audit events to record, who can read those logs, and how long they are retained. For managed clusters, confirm which logs and network restrictions are available in the provider's control plane.
A small-team review routine
Before a change, verify the context and namespace, use an identity scoped to the task, and review the manifest for privileges, service-account access, Secret mounts, and network exposure. For a live incident, inspect the affected namespace and resource first; avoid dumping all Secrets or making a broad permission change as a shortcut.
On a regular schedule, review RBAC bindings and service accounts, remove stale credentials, check whether cluster and workload policies still match the application, and confirm that audit logs and backups meet your recovery needs. Record who owns each action—application team, cluster administrator, or provider—so an important control is not left assumed.
Getting comfortable with kubectl makes this work easier, but security comes from the controls around the command: a known target, narrowly scoped permissions, protected credentials, constrained workloads, and a cluster configuration that someone is responsible for reviewing.