A talk look at the rise of infrastructure as code, and the security challenges that go along with it. Discusses some patterns that tools are starting to adopt to help.
Agenda Configuration security 01 Applying policy to configuration 02 An example ecosystem: Kubernetes 03 An example ecosystem: Terraform 04 Patterns for addressing the problem 05
A brief history of configuration management Original research and theory, mainly focused on reliability in US Military systems. IT service management grew from UK Government efficiency drives in the early 90s/2000s and talked about config management. Infrastructure as code became popular mid-2000s, in particular with systems administrators. 1950s research, 1960s 480 series, 1991 MIL-HDBK-61
Configuration is everywhere Azure ARM 250k+ Terraform 200k+ Kubernetes 2m+ AWS CF 90k+ Serverless 40k+ Compose 600k+ Sense of scale of infrastructure as code in public repositories on GitHub
Security misconfiguration is the most commonly seen issue. This is commonly a result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage... “ “ Configuration is a security risk https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration
While CSPs often provide tools to help manage cloud configuration, misconfiguration of cloud resources remains the most prevalent cloud vulnerability “ “ Configuration is a security risk
policy a set of ideas or a plan of what to do in particular situations that has been agreed to officially by a group of people, a business organization, a government, or a political party. Cambridge Dictionary noun [ C ] UK /ˈpɒl.ə.si/ US /ˈpɑː.lə.si/
policy a set of ideas or a plan of what to do in particular situations that has been agreed to officially by a group of people, a business organization, a government, or a political party. Cambridge Dictionary noun [ C ] UK /ˈpɒl.ə.si/ US /ˈpɑː.lə.si/ All Go projects should have been updated to use Go 1.15
policy a set of ideas or a plan of what to do in particular situations that has been agreed to officially by a group of people, a business organization, a government, or a political party. Cambridge Dictionary noun [ C ] UK /ˈpɒl.ə.si/ US /ˈpɑː.lə.si/ All Go projects should have been updated to use Go 1.15 Our open source projects should all use the Apache 2.0 license
policy a set of ideas or a plan of what to do in particular situations that has been agreed to officially by a group of people, a business organization, a government, or a political party. Cambridge Dictionary noun [ C ] UK /ˈpɒl.ə.si/ US /ˈpɑː.lə.si/ All Go projects should have been updated to use Go 1.13 Our open source projects should all use the Apache 2.0 license Dockerfiles should all have a maintainers label and not use FROM with images tagged latest
Insecure by default Limits to prevent denial of service CPU and Memory Limits spec: containers: - name: db image: mysql resources: limits: memory: "128Mi" cpu: "500m" Limiting the expected CPU and Memory limits has operational as well as security benefits. In the context of security this is about limiting the impact of potential denial of service attacks to affecting the app rather than the node and potentially the whole cluster.
Insecure by default Root level permissions by default runAsNonRoot apiVersion: v1 kind: Pod metadata: name: hello-world spec: containers: ... securityContext: readOnlyRootFilesystem: true runAsNonRoot: true By default, containers can run as the root user. This property prevents that at the container runtime level, meaning an attacker would only have limited permissions if they we’re to be able to execute a command in the context of the container.
Insecure by default Writable file systems making attackers lives easier readOnlyRootFilesystem apiVersion: v1 kind: Pod metadata: name: hello-world spec: containers: ... securityContext: readOnlyRootFilesystem: true runAsNonRoot: true By default the file system mounted for the container will be writable. That means an attacker who compromises the container can also write to disk, which makes certain attacks easier. If you’re containers are stateless then you don’t need a writable filesystem.
Insecure by default Access to all the power of linux by default Capabilities apiVersion: v1 kind: Pod metadata: name: hello-world spec: containers: ... securityContext: capabilities: add: ["NET_ADMIN", "SYS_TIME"] drop: ["ALL"] Linux capabilities control at a low-level what processes in the container can do. From being able to write to disk to being able to communicate over the network. Dropping all capabilities and adding in those that are required is possible but requires understanding the list of capabilities.
Insecure by default Pod access to the API server Automounting Service Account tokens apiVersion: v1 kind: ServiceAccount metadata: name: build-robot automountServiceAccountToken: false By default Pods can use the Kubernetes API with the default Service Account, which often means then can access all of the APIs. If a pod gets compromised that’s terrible. You can also explicitly set this to false for Pods as well.
Insecure Terraform Can you spot issues in the following code? resource "aws_security_group_rule" "my-rule" { type = "ingress" cidr_blocks = ["0.0.0.0/0"] } resource "aws_alb_listener" "my-alb-listener" { port = "80" protocol = "HTTP" } resource "azurerm_managed_disk" "source" { encryption_settings { enabled = false } } Use of unencrypted transport protocol
75% said they were somewhat or not confident in spotting issues via manual review Recent survey of 455 professionals. From architects and CIOs to application developers and operations and security specialists
50% rely on manual code review or penetration tests Recent survey of 455 professionals. From architects and CIOs to application developers and operations and security specialists
Static analysis Static program analysis is the analysis of computer software that is performed without actually executing programs 1. Fast and automated feedback
Local Local tools can help developers write security conscious configuration, from integrating with unit test workflows to prompts in IDEs Feedback Completeness Local developer tools 2. Understand SDLC tradeoffs
Local Local tools can help developers write security conscious configuration, from integrating with unit test workflows to prompts in IDEs Feedback Fastest Completeness Low Local developer tools 2. Understand SDLC tradeoffs
Local CI/CD Local tools can help developers write security conscious configuration, from integrating with unit test workflows to prompts in IDEs Quickly fail the build for potentially insecure configuration files or those that don’t meet some internal policy. Feedback Fastest Completeness Low In CI/CD pipelines 2. Understand SDLC tradeoffs
Local CI/CD Local tools can help developers write security conscious configuration, from integrating with unit test workflows to prompts in IDEs Quickly fail the build for potentially insecure configuration files or those that don’t meet some internal policy. Feedback Fastest Fast Completeness Low Variable In CI/CD pipelines 2. Understand SDLC tradeoffs
Local CI/CD Repositories Local tools can help developers write security conscious configuration, from integrating with unit test workflows to prompts in IDEs Quickly fail the build for potentially insecure configuration files or those that don’t meet some internal policy. Configuration is often stored in a source control system and checks can be integrated with pull requests. Feedback Fastest Fast Completeness Low Variable In source code repositories 2. Understand SDLC tradeoffs
Local CI/CD Repositories Local tools can help developers write security conscious configuration, from integrating with unit test workflows to prompts in IDEs Quickly fail the build for potentially insecure configuration files or those that don’t meet some internal policy. Configuration is often stored in a source control system and checks can be integrated with pull requests. Feedback Fastest Fast Slower Completeness Low Variable Medium In source code repositories 2. Understand SDLC tradeoffs
Local CI/CD Repositories Production Local tools can help developers write security conscious configuration, from integrating with unit test workflows to prompts in IDEs Quickly fail the build for potentially insecure configuration files or those that don’t meet some internal policy. Configuration is often stored in a source control system and checks can be integrated with pull requests. The Kubernetes or Cloud API represents the actual running configuration. Feedback Fastest Fast Slower Completeness Low Variable Medium In production 2. Understand SDLC tradeoffs
Local CI/CD Repositories Production Local tools can help developers write security conscious configuration, from integrating with unit test workflows to prompts in IDEs Quickly fail the build for potentially insecure configuration files or those that don’t meet some internal policy. Configuration is often stored in a source control system and checks can be integrated with pull requests. The Kubernetes or Cloud API represents the actual running configuration. Feedback Fastest Fast Slower Slow Completeness Low Variable Medium High In production 2. Understand SDLC tradeoffs
Local CI/CD Repositories Production Local tools can help developers write security conscious configuration, from integrating with unit test workflows to prompts in IDEs Quickly fail the build for potentially insecure configuration files or those that don’t meet some internal policy. Configuration is often stored in a source control system and checks can be integrated with pull requests. The Kubernetes or Cloud API represents the actual running configuration. Feedback Fastest Fast Slower Slow Completeness Low Variable Medium High Tradeoffs all the way down 2. Understand SDLC tradeoffs
Most (77%) of respondents wanted to shift more configuration to developers, but only ~33% have done so to date 3. Don’t just optimise for experts Recent survey of 455 professionals. From architects and CIOs to application developers and operations and security specialists
3. Don’t just optimise for experts Recent survey of 455 professionals. From architects and CIOs to application developers and operations and security specialists Lack of expertise drives low adoption. Mentoring (41%), training (37%), tools (28%) all mentioned
Infrastructure is increasingly part of the app Your configuration is in the same repo as your code, maintained by the same developers and going through CI
Shift security left Automatically catching security issues during development means less issues in production, and more time to focus on finding and fixing them
garethr
hato3isfriend
tacck
oracle4engineer
yuyakakizaki08
junkifurukawa
techtekt
yumayabe
miyayou
jordihofc
microcms
irof
skrb
tanoku
michaelherold
jeffersonlam
reverentgeek
davidbonilla
kneath
lauravandoore
jensimmons
sonatard
thoeni
bryan
sugarenia