Upload
others
View
6
Download
0
Embed Size (px)
Citation preview
Confidential & Proprietary
Container securityMar 2017
Maya Kaczorowski (kaczorowski@)Product Manager
Container security 101
First, what’s a container?An application bundle
A process group with some restrictions
VM: Starting an OSBooting phone: ~60 secondsMutable data: mixed with image
Container: Starting a processTap an app: ~0.2 secondsMutable data: stored elsewhere
Confidential & Proprietary
First, what’s a container?Container
Hardware Hardware
Host OS Host OS
App
VM
App App
VM
Guest OS
Virtual machinevs
Container Runtime
Bins/libs Bins/libs
Bins/libsApp
Guest OSBins/libs
App
Hypervisor
Confidential & Proprietary
Containers bring new challenges
Service Discovery
Monitoring
Dynamic Scheduling
Scaling
Isolation
Updates
Remediation
Access Control Security
Confidential & Proprietary
KubernetesGreek for “Helmsman”; also the root of the words “governor” and “cybernetic”
• Manages container clusters
• Inspired and informed by Google’s experiences and internal systems
• Supports multiple cloud and bare-metal environments
• Supports multiple container runtimes
• 100% Open source, written in Go
Manage applications, not machines
Confidential & Proprietary
So one of the first things to do is study up on what controls are there and use them to strengthen your security posture
– Chenxi Wang, Jane Bond Project
Kubernetes is so new that lots of practitioners don’t know what security controls come with it.
Confidential & Proprietary
How is securing a container different than a VM?How containers help
Containers run on a minimalist host OS which limits the surface of attack
How containers hurt
Hypervisors remain a small surface area with a strong security boundary
Surface of attack
Resource isolation
Root permissions
Lifetime
Access to container host resources are separated using namespaces
Users need to properly configure namespaces, and not all host resources are well separated
Access controls like privilege controls app and shared resources, but not root resources outside the container
Containers have access to wider set of syscalls to the kernel
Containers have a shorter average lifetime, meaning that an attacker has a shorter window of opportunity and less chance to persist
It’s harder to do forensics when a compromised container is no longer there
What kinds of threats are there to containers?
➢ Hackers accessed the Kubernetes console, which was not password protected
➢ Console contained privileged AWS account credentials
➢ Used credentials to access AWS resources and mine cryptocurrency
Is my container image secure to build and deploy?
● Unpatched vulnerability
● Supply chain vulnerability
● Zero day exploit on common library
Is my container secure to run?
● DDoS
● Node compromise and exploit
● Container escape
● Flood event pipeline
Is my infrastructure secure for developing containers?
● Kubernetes API compromise
● Privilege escalation
● Credential compromise
What kinds of threats are there to containers?Although containers have slightly different security models than VMs, a lot of the threats are quite familiar
Software supply chain Runtime securityInfrastructure security
Is my container image secure to build and deploy?
● How you make sure your container images are vulnerability-free, and
● How you make sure the images you built aren’t modified before they are deployed
Is my container secure to run?
● How you identify a container acting maliciously in production, and
● How you take action to protect your workload
Is my infrastructure secure for developing containers?
● How you use Kubernetes security features to protect your identities, secrets, and network
● How GKE uses native GCP functionality, like IAM, audit logging, and networking
So, what is container security?
Confidential & Proprietary
Like all security, everything depends on your threat model
The security choices you make should be reflective of your threats - based on the assets you’re protecting and the attackers who would be interested in those assets
You wouldn’t protect dev the same way as test the same way as prod
Why GKE security?
Confidential & Proprietary
Google Kubernetes Engine patches you to the latest version, automatically. This keeps you up to date with security patches and with new features
Google Kubernetes Engine provides common best practices with security by default. There will always be app-level hardening and tuning to do
Google Kubernetes Engine provides the best of Google Cloud Platform security features, with integrations with IAM, Audit Logging, VPC, and more
1
2
3
Why GKE security?
Confidential & Proprietary
Keep your Kubernetes
version up to date!
The simplest thing you can do to improve your security is...
Confidential & Proprietary
Master versions● Choose your version, and
Google will automatically apply new master patches
● Last stable version by default
● Last 3 major versions supported
Node versions● Optionally enable node autoupgrade for a
cluster or nodepool● Can also schedule a maintenance window for
upgrades to occur (Beta)● Note that nodes cannot have more recent
versions than their master
GKE simplifies upgrades
v1.8.8-gke.0Security vulnerability announced
v1.8.9-gke.1Security patch applied
Confidential & Proprietary
Meltdown Spectre
Speculative execution
Confidential & Proprietary
Where should you start?
Building blocksLinux
● Namespaces● Cgroups● Capabilities
Best practicesLinux extras
● seccomp● AppArmor
Best practicesGoogle Kubernetes Engine
● Min IAM roles● Metadata concealment● Authorized networks● Private clusters
Best practicesKubernetes
● Current release● K8s namespaces● RBAC● Network policy
Cutting edgeFeatures in development
Maturity
● Audit logging● Taints/ tolerations● Security context
Confidential & Proprietary
Best practices to harden your clusters
seccomp
Audit Logging
Min IAM rolesGKE
Network policy
Pod Security Policy
RBAC
Kubernetes
AppArmor
Taints/tolerations
Authorized networksPrivate clusters
Metadata concealment
Linux extras
K8s namespacesCurrent release
Minimal OS
Limit syscalls
Log actions for review and automated alerting
Create a limited service account just to manage GKE
Limit pod to pod traffic by whitelist
Set restrictions for running pods in a cluster
Set permissions at the namespace level, by role
Limit filepath accesses for the program
Prevent nodes from running certain pods
Limit access to the API server to certain IP addresses onlyProtect user pods from accessing node metadata
Separate workloadsMaintain the latest version of Kubernetes
Limit the surface of attack
Use only private IPs in the RFC1918 space for a cluster master and nodes
Confidential & Proprietary
Problem: I have too much stuff!• Name collisions in the API• Poor isolation between users• Don’t want to expose sensitive data
Solution: Slice up the cluster• Create new namespaces as needed
• per-user, per-app, per-department, etc.• Namespaces are just another API object• Provide each user community with its own:
• Resources, by name• Policies, with delegated management• Resources, with consumption limits
K8S: Kubernetes namespaces
Confidential & Proprietary
K8S: RBAC
Namespace Role Binding Role
Confidential & Proprietary
K8S: NetworkPolicy
How does K8S networking work?
● IPs are cluster-scoped
● Pods can reach each other directly, even across nodes
● No brokering of port numbers
Confidential & Proprietary
K8S: NetworkPolicy
How does K8S networking work?
● IPs are cluster-scoped
● Pods can reach each other directly, even across nodes
● No brokering of port numbers
With NetworkPolicy:
Restrict pod-to-pod traffic
Confidential & Proprietary
Feature availability
Audit Logging
Min IAM rolesGKE
Network policy
Pod Security Policy
RBAC
Kubernetes
Taints/tolerations
Authorized networksPrivate clusters
Metadata concealment
K8s namespacesCurrent release
Minimal OS
Beta in 1.10Stable
Beta in 1.10
Default from 1.6+
Kubernetes
Stable
--
Not provided
Beta, default in 1.8.3+
Self-serve
Beta
Beta in 1.8.6+
Default from 1.6+
Google Kubernetes Engine
Beta
BetaBeta
Beta*
Self-serveUp to date
COS by default
Confidential & Proprietary
Identity & Access Management
Cloud Audit Logging
Virtual Private Cloud
Manage your users and permissions at the project level
This doesn’t stop you from using Kubernetes RBAC - but lets you more easily manage this across projects
Review, monitor and alert on audit logs centrally
This makes Kubernetes audit logs easier to consume along with all your other audit logs
Connect your cloud resources to each other on a private network
This lets you plug in Kubernetes into your broader network, the way you want to
GKE leverages Google Cloud security features
Confidential & Proprietary
Encryption at rest by default
Authentication and encryption in transit by default
Secure boot with Titan chips
Proprietary network cables
https://cloud.google.com/security/security-design/
Confidential & Proprietary
A container is not a strong security boundary
● Kubernetes namespaces are meant to segment resources, but you may not want to rely on these to actually ‘contain’ a malicious process○ A malicious process could escape the container and execute host-level
operations
● What’s the alternative?○ Node - hypervisors are a relatively strong security boundary○ Project - in Google Cloud Platform, isolation is at the project level