Kubernetes Foundations: Services, Configuration, and Least-Privilege Access

Services select endpoints

A Service gives clients a stable discovery name and virtual access point while Pods come and go. Its selector identifies matching Pods; readiness influences which endpoints are eligible for ordinary traffic. A Service whose selector matches nothing can exist successfully but send traffic nowhere.

Separate port from targetPort: clients use the Service port, while the backend process listens on the target port. A wrong target port can look like a network failure even though discovery is working. In a disposable cluster, inspect the Service, EndpointSlices, Pod labels, readiness, and the application's listening address before changing network policy.

Internal discovery is not external exposure

A ClusterIP Service is generally an internal cluster endpoint. External access needs a separate design, such as an ingress/gateway controller or a load-balancer Service supported by the environment. Creating an Ingress object without a controller does not create a functioning HTTP gateway.

DNS names can include the Service and namespace. Using a short name implicitly relies on the caller's namespace search context. Make cross-namespace dependencies explicit and avoid assuming that an application's local development hostname has the same meaning inside a Pod.

Configuration is a rollout concern

A ConfigMap stores non-sensitive configuration. A Secret stores values that require stronger handling, but base64 encoding is not encryption. Protect Secrets with API access policy, encryption-at-rest configuration where supported, and disciplined operational access. Do not commit real secrets to a manifest repository or copy them into application logs.

Environment variables are fixed when a container starts. Updating the ConfigMap does not mutate the environment of a running process. Mounted configuration can update under certain conditions, but the application must reload it; subPath mounts do not receive ordinary projected volume updates. Decide whether a configuration change requires a rollout and make that policy visible in deployment automation.

Namespaces are not a complete security boundary

A namespace organizes resources and scopes many names, quotas, and permissions. It does not automatically isolate Pod network traffic. NetworkPolicy enforcement requires a compatible networking implementation, and policies should be tested with both allowed and denied traffic. Host access, privileged workloads, and cluster-scoped permissions can cross namespace assumptions.

Use a dedicated ServiceAccount for a workload that needs Kubernetes API access. Grant only the required verbs and resources through RBAC. If the workload does not call the API, evaluate disabling automatic service-account token mounting. Avoid giving an application broad cluster administrator privileges to solve one missing permission.

Verify the complete path

Test DNS resolution, an internal request, readiness removal, and a configuration rollout independently. Confirm that a Pod using the wrong label is not selected. Then verify a denied API operation with the workload's ServiceAccount. These checks distinguish discovery, traffic routing, application configuration, and authorization failures instead of collapsing all of them into "Kubernetes networking is broken."