Kubernetes 1.8 separates API authority from network access

Permission to change a Kubernetes object and permission to contact an application are different decisions. A service account might have no authority to list Pods while its workload can still open a connection to another service. The Kubernetes 1.8 announcement addresses both boundaries. RBAC becomes stable, and NetworkPolicy gains beta support for filtering outbound traffic.

These changes matter together because application isolation cannot be inferred from a single policy system. RBAC controls operations through the Kubernetes API. NetworkPolicy describes allowed traffic for selected Pods. Each answers a different question about what a workload or its associated identity may do.

I prefer security configuration whose scope is evident from the object being configured. Kubernetes 1.8 makes more of those decisions available through its API, but the distinction between the policy systems remains essential. A Role is not a connectivity rule, and a connectivity rule does not grant access to the API objects that describe a service.

Stable RBAC retains its resource-oriented model

RBAC lets administrators define roles and access policies through the Kubernetes API. Its stable status follows the beta introduced in 1.6. The April RBAC guidance explains the operational difference from Kubernetes' ABAC implementation, which requires authorization file changes on the master and an API server restart for policy updates.

Roles describe permissions, and bindings assign them to subjects. A namespace-scoped RoleBinding grants its referenced permissions within that namespace. A ClusterRoleBinding grants a ClusterRole across the cluster. These objects make the scope of an API grant part of the configuration that an administrator can inspect and change without editing the master's filesystem.

The April guidance also explains a migration complication that remains relevant when evaluating authorization. If ABAC and RBAC are enabled together, a request succeeds if either authorizer permits it. A narrow RBAC grant cannot remove broader access that ABAC continues to allow. Stable RBAC does not make the other enabled authorizer disappear.

Application service accounts are a concrete reason to care about this boundary. An application that uses the Kubernetes API needs permission for the operations it performs. Its ability to authenticate with a token is separate from whether it can list, create or modify a given resource. Removing broad legacy authorization can therefore expose an application dependency that was previously hidden by permissive policy.

Egress policy describes the caller's allowed destinations

Earlier NetworkPolicy support filters incoming traffic to a Pod. Kubernetes 1.8 adds outbound filtering as beta. This lets an administrator describe traffic from the perspective of the workload initiating it, rather than relying only on what each destination permits to arrive.

The 1.8 NetworkPolicy API types expose egress and policyTypes under networking.k8s.io/v1. Comments explicitly mark the new fields as beta-level in this release. The API group version and the maturity of each newly added capability are consequently different pieces of information.

A policy selects Pods through podSelector. An empty selector matches every Pod in the policy's namespace. Egress rules then describe permitted destination ports and peers. Peers can identify Pods in the same namespace, select namespaces or name an IP block. The version's peer definition requires exactly one of those fields, so examples should not combine selectors using syntax from a different API revision.

This gives connectivity a declarative representation, but the implementation still depends on a suitable network plugin. The 1.7 release announcement states that dependency for NetworkPolicy enforcement. Extending the API with egress rules does not turn object storage into a packet filter. The selected network implementation must support the behavior being requested.

An empty rule list has direction-dependent meaning

Consider a namespace named batch whose workloads should have no outgoing access unless another policy explicitly allows it. The following object describes an egress isolation baseline. It assumes a network implementation supporting the beta egress capability.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: isolate-egress
  namespace: batch
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress: []

The explicit Egress entry matters. The API source explains that a policy with no egress section otherwise defaults to ingress behavior. An administrator cannot express a no-egress policy merely by omitting the new fields and assuming the absence means the intended direction. Naming the direction makes the empty allow list meaningful.

This object does not disable incoming traffic. Its policyTypes contains only Egress, and incoming connectivity remains subject to other applicable configuration. Direction is part of the policy's meaning, not an incidental detail of how the manifest is written.

The baseline is also not an overriding deny rule. NetworkPolicy combines applicable allow rules additively. Another policy selecting the same Pods can permit outgoing traffic. Reading just the isolation object is therefore insufficient to describe the effective set of allowed destinations. The relevant configuration includes every policy that selects those Pods for the direction in question.

That model supports composing a namespace baseline with more specific grants. It also means the word "deny" can mislead if it suggests a rule that cancels every later allowance. The API represents allowed traffic, and an empty set of allowances provides isolation only in the absence of applicable grants elsewhere.

Destination and port constraints work together

An egress rule must match both its destination and its port constraints. Within the port list, entries combine as alternatives. Within the destination list, peers also combine as alternatives. If either list is missing or empty, that part of the rule matches all ports or all destinations, respectively.

For example, a rule that specifies a destination but omits ports grants access to all ports at that destination. A rule that specifies ports but omits destinations permits those ports without restricting the destination. These are different policies even if both look like short fragments beneath egress.

The same source defines TCP as the default protocol when none is supplied. It also allows numeric or named ports. Explicit protocol and port fields can make the intention easier to inspect when a workload requires more than one kind of connection. The mechanism remains a network permission, with no knowledge of the application's business operation behind that connection.

IP blocks include an optional list of excluded CIDRs. The source requires those exclusions to fall within the containing CIDR. That permits a destination range to be described without enumerating every included address, while retaining a precise boundary for the exception. It does not attach a workload identity to the addresses.

The choice between a Pod selector and a namespace selector also changes the grant. A peer's Pod selector selects Pods within the policy's own namespace. A namespace selector matches all Pods in the namespaces it selects. An empty namespace selector consequently has a wider meaning than an empty Pod selector. Both are syntactically short, but they identify different sets of peers according to the API definition.

For the isolated batch example, even a supporting service such as DNS needs an applicable outbound allowance if workloads are to reach it. A workload's familiar behavior does not exempt the corresponding network request. The required destinations must be expressed through the policy model along with the application's other connections.

Workload APIs develop alongside the policy model

The release promotes the core workload APIs to the apps/v1beta2 group and version. That beta includes Deployments, DaemonSets, ReplicaSets and StatefulSets. CronJobs also reach beta for scheduled batch work. These are useful advances for application management, but the announcement does not describe the workload APIs as generally available in this release.

Custom Resource Definitions remain beta. The announcement identifies Operators for complex stateful systems as one use case and describes validation as continuing stabilization work. A platform can add an API for an application-specific operation, yet the extension still needs its own implementation of the behavior behind that API.

Kubelet TLS certificate rotation reaches beta as well. It addresses the lifecycle of credentials used by node components, alongside the release's API authorization and network controls. These mechanisms interact operationally because the same cluster must maintain credentials, authorize operations and enforce connectivity. Their enforcement locations remain distinct.

My judgment of the release depends on that explicitness. Workload objects describe what should run, RBAC limits who may operate on API resources, and egress policy describes where selected Pods may send traffic. The no-egress example is useful because it makes the details inspectable, including the named direction and the fact that other applicable policies can still add allowed destinations.