Cloud and software-defined networking

Networks are increasingly defined in software. Software-defined networking separates the decisions about where traffic should go from the devices that forward it; cloud platforms let customers create entire virtual networks with an API call; containers and orchestration platforms build networks that appear and disappear in seconds; and infrastructure as code describes all of it in text files. This changes how network security is designed, enforced and audited. This lesson covers SDN and network virtualization, cloud virtual networks and their controls, connectivity to the cloud, container networking and the security of the automation that builds it all. Cloud service and deployment models in general are covered in CISSP-112 lesson 7.

Software-defined networking

Traditional network devices combine a control plane, which decides where traffic goes by running routing protocols and building tables, and a data plane, which forwards packets according to those tables, in every box. Software-defined networking, SDN, centralizes the control plane in a controller that programs many forwarding devices through southbound interfaces, such as OpenFlow or vendor APIs, and exposes northbound APIs to applications and orchestration tools. The result is a network that can be configured as a whole, consistently and quickly, rather than box by box.

SDN brings security benefits: consistent policy across the network, rapid response such as quarantining a compromised host with one change, central visibility and integration with security tools. It also concentrates risk. The controller becomes a high-value target, since whoever controls it controls the network; its APIs must be authenticated, authorized and logged; the channel between controller and devices must be encrypted and mutually authenticated; and the controller must be highly available, because losing it can freeze or break the network. Network function virtualization, NFV, a related idea, runs functions such as firewalls, load balancers and routers as software on standard servers instead of dedicated appliances.

Overlays and network virtualization

Virtualized data centres and clouds build virtual networks on top of a physical underlay using overlay protocols. VXLAN, virtual extensible LAN, wraps layer 2 frames in UDP packets, using a 24-bit identifier that allows about 16 million segments compared with 4,094 VLANs; Geneve is a more flexible successor used by several platforms. Overlays let tenants and applications have their own networks independent of the physical topology. They also create blind spots: traditional network monitoring tools that watch the physical network see only encapsulated traffic between hypervisors, so visibility must come from the virtualization layer, through virtual taps, flow logs or the platform's own security tools. Hypervisors and virtual switches enforce isolation between tenants; a flaw that lets traffic escape from one tenant's network to another's is among the most serious cloud vulnerabilities, and providers invest heavily to prevent it.

Cloud virtual networks

In infrastructure as a service, customers build virtual private clouds, called VPCs on Amazon Web Services and Google Cloud and virtual networks, VNets, on Microsoft Azure. A virtual network has an address range, subnets, route tables, internet and NAT gateways and a range of security controls. Under the shared responsibility model, the provider secures the physical network and the virtualization layer, and the customer is responsible for how they configure their virtual network: which subnets are public, which ports are open, how traffic is routed and logged. Misconfiguration, not provider failure, causes the great majority of cloud security incidents.

Two layers of filtering are common. Security groups are stateful filters attached to individual instances or network interfaces; they usually allow only explicit permits, and return traffic is allowed automatically. Network access control lists, on platforms that offer them, are stateless filters attached to subnets, evaluated in rule order, with explicit allow and deny rules, so return traffic must be allowed separately. Security groups can reference other security groups rather than IP addresses, so a rule can say "allow the application tier to reach the database tier" and keep working as instances scale up and down. Cloud-native firewalls and third-party virtual appliances add deeper inspection where needed.

Connecting to the cloud

Organizations connect on-premises networks to cloud networks in several ways. Site-to-site IPsec VPNs over the internet are quick and inexpensive. Dedicated private connections, such as AWS Direct Connect, Azure ExpressRoute and Google Cloud Interconnect, give predictable performance through a carrier or colocation facility but are not encrypted by default; organizations add IPsec or MACsec where confidentiality is required. Within the cloud, peering connects virtual networks to each other, and transit gateways or hub networks connect many networks in a hub-and-spoke design, often with central inspection in the hub. Private endpoints let workloads reach provider services such as storage and databases over the provider's private network rather than across public endpoints, which reduces exposure and supports data exfiltration controls.

Egress control deserves special attention. By default, many cloud networks allow instances to reach anywhere on the internet, which helps attackers who compromise a workload to download tools and send data out. Mature designs route outbound traffic through central NAT and firewall points with allow lists of required destinations, use private endpoints for provider services and alert on unusual outbound volumes. Metadata service protections, discussed in lesson 2, block a common route from server-side request forgery to stolen credentials.

Container and Kubernetes networking

Containers package applications with their dependencies and share the host operating system's kernel. Orchestration platforms, Kubernetes above all, schedule containers in groups called pods across clusters of nodes. By default, Kubernetes networking is flat: every pod can reach every other pod in the cluster, across all namespaces. Network policies, enforced by the cluster's network plugin, restrict which pods can talk to which, based on labels and namespaces; without them, a compromised pod can reach databases and internal services freely. A common baseline is a default-deny policy in each namespace, followed by explicit allows for required flows.

Service meshes, such as Istio and Linkerd, add a proxy beside each service that handles traffic between services, providing mutual TLS between workloads, identity-based authorization policies, retries and detailed telemetry. They bring zero trust principles to service-to-service communication but add complexity. Ingress controllers and API gateways manage traffic entering the cluster and should be protected with TLS and web application firewall capabilities. The cluster's control plane, the API server, is the most critical component: it should not be exposed to the internet without strong authentication, and access should follow least privilege through role-based access control.

# A simple model of Kubernetes-style network policy: default deny, then explicit allows by label
allow = {
    ('frontend', 'api'): {8080},
    ('api', 'db'): {5432},
    ('api', 'cache'): {6379},
}
flows = [('frontend', 'api', 8080), ('frontend', 'db', 5432), ('api', 'db', 5432),
         ('cache', 'db', 5432), ('api', 'cache', 6379), ('frontend', 'api', 22)]
for src, dst, port in flows:
    ok = port in allow.get((src, dst), set())
    print(f"{src:9s} -> {dst:6s} port {port:5d}: {'ALLOW' if ok else 'deny'}")

frontend  -> api    port  8080: ALLOW
frontend  -> db     port  5432: deny
api       -> db     port  5432: ALLOW
cache     -> db     port  5432: deny
api       -> cache  port  6379: ALLOW
frontend  -> api    port    22: deny

Infrastructure as code and automation

Cloud and SDN networks are usually built with infrastructure as code, IaC: templates such as Terraform, AWS CloudFormation, Azure Bicep or Kubernetes manifests that describe the desired network in text. IaC has strong security benefits. Configurations are version-controlled, peer-reviewed and repeatable, so drift is visible and environments can be rebuilt consistently. Policy as code tools can scan templates before deployment and block, for example, security groups open to the whole internet or storage without encryption. The risks move to the pipeline: whoever can change templates or the deployment pipeline can change the network, so repositories need branch protection and reviews, pipelines need least-privilege credentials stored in secret managers, and changes made by hand in the console should be detected as drift and reconciled.

Cloud security posture management, CSPM, tools continuously compare deployed resources with policies and benchmarks such as the Center for Internet Security foundations benchmarks, reporting exposed services, overly broad rules and missing logs. Cloud-native application protection platforms combine posture management with workload protection and identity analysis. These tools are only as good as the processes that act on their findings, so assign owners and service levels for remediation.

Visibility in software-defined networks

Software-defined and cloud networks change how monitoring works. There may be no physical cable to tap, workloads may exist for minutes, and addresses are reused constantly. Visibility comes from flow logs, which record source, destination, ports, bytes and whether traffic was accepted or rejected; packet mirroring services that some providers offer; DNS query logs; load balancer and API gateway logs; and the control plane's own audit logs, which record who changed a security group or route table and when. Logs should be sent to a central system outside the account or subscription they describe, so an attacker who compromises an environment cannot erase the evidence. Because identifiers change, logs must be enriched with labels and asset context at the time they are collected.

Thinking like a manager

In the cloud, the network is code and the customer owns its configuration. Questions in this area often describe an exposed resource or an unexpected flow; the best answers fix the immediate exposure and the process that allowed it, such as policy as code, posture management and change review. When choosing between controls, remember that security groups are stateful and per-workload, network ACLs are stateless and per-subnet, and both are needed only where they add value. For SDN and Kubernetes, protect the control plane first: the controller or API server is the key to everything else.