Cloud Security
Cloud Security tests how responsibility is divided in cloud services, how Juniper firewalls are deployed in virtual and containerized form, and how segmentation and encryption control east-west and north-south traffic.
Shared responsibility
The provider secures the physical facility, hardware, hypervisor, and the managed service layer. The customer secures what it puts in the cloud: identities, data, configurations, and-for IaaS-the guest OS and patched applications. The split moves with the service model: in SaaS the customer mostly manages users and data; in IaaS the customer manages far more.
Juniper security products
vSRX is a virtual SRX firewall for VM environments. cSRX is the containerized SRX form factor, suited to container and Kubernetes east-west protection. SRX security features include zones, security policies, NAT, IPS, AppSecure, and IPsec VPN. Junos security policy is evaluated in order, and the implicit default is deny.
Segmentation and encryption
Microsegmentation limits lateral movement by applying policy between workloads rather than only at the perimeter. Cloud security groups provide instance-level, stateful filtering; network ACLs are stateless subnet-level filters. Encrypt data in transit with IPsec or TLS and data at rest with provider KMS or customer-managed keys. Apply least-privilege IAM and avoid long-lived credentials.
Worked example
A Kubernetes application must inspect traffic between two namespaces and allow only TCP 443 from the client namespace to the server namespace. A VM-based vSRX does not naturally sit inside the pod network, so deploy cSRX as the containerized inspection point or insert it through a service chain. Define client and server zones, allow TCP 443 from client to server, deny everything else explicitly, and log the deny. Use Kubernetes network policy for basic L3/L4 isolation and cSRX for deeper inspection.
Traps that cost marks
Do not say the provider secures “everything” in IaaS; the customer still owns the guest OS and data. Do not mix up stateful security groups and stateless ACLs. Do not choose vSRX when the requirement is container-level insertion-cSRX is the containerized option. Do not forget that IPsec needs matching proposals, traffic selectors, and pre-shared-key or certificate settings. Do not assume an explicit permit overrides a earlier deny.
Key points
- Shared responsibility varies by service model; the customer always retains identity, data, and configuration responsibility.
- vSRX is virtual-machine based; cSRX is containerized and fits Kubernetes east-west inspection.
- Junos security policies are order-dependent, with an implicit default deny.
- Security groups are stateful; network ACLs are stateless.
- Use microsegmentation, least-privilege IAM, and IPsec/TLS plus at-rest encryption.