Secure_Container_Workload.pdf

2
Secure Container Workload
Contents
1. Container architecture
2. Container security layers
3. Image security
4. Container orchestration security
5. Container scanning via Amazon Elastic Container Registry Scan
6. Container scanning via Amazon Inspector
7. Implement security patch in container

3
Document Revisions
Date Description
2022/12/02 First publication by Kimi Huang

4
1. Container architecture
What are containers?
Containers are lightweight packages of your application code together with
dependencies such as specific versions of programming language runtimes
and libraries required to run your software services. (Defined by Google
Cloud)
Figure 1 shows the architecture of virtual machines and containers. The
key differentiator between containers and virtual machines is that virtual
machines virtualize an entire machine down to the hardware layers and
containers only virtualize software layers above the operating system level.
Figure 1. Containers vs Virtual Machines

5
2. Container security layers
Figure 2 shows the architecture of container security layers. The container
security layers can split to 4 layers: Host OS, Container Orchestration,
Container, and Application.
Host OS: The Host OS could be an Amazon Machine Image (AMI)
installed on Amazon Elastic Compute Cloud instance (Amazon EC2) or an
operation system installed on your On-Premises environment.
Container Orchestration: There are many tools to establish a Container
Orchestration. OpenShift developed by RedHat, Kubernetes developed by
CNCF, or Amazon Elastic Container Service (ECS) developed by Amazon
Web Service.
Container: Containers are a form of operating system virtualization. You
can use Docker or Podman as a container engine to build a container with
Dockerfile.
Application: Bundled the application dependencies, libraries, and
configuration files need to run to a container.
All these 4 layers have different life cycle you need to take care to update
with latest patch.
Figure 2.The architecture of container security layers

6
3. Image security
3.1 Base image
To build a container image we always use a base image as a baseline.
This base image might come from an untrust image repository. Choice a
trust image repository with latest patch version to keep your container
image up to date.
Figure 3 presented a python official image repository authorized by Docker
Hub.
Figure 3. Python official image repository of Docker Hub
It’s good practice to use “minimal” images, which are as small in size as
possible (which is a good advantage anyway), and contain as few tools as
possible. Minimal images go even beyond what “size-optimized” images
(such as alpine or <something>:<version>-slim, e.g. python:3.8-slim) do:
they come without any package manager. This makes it hard for an
attacker to load additional tools.
3.2 Permission of container
Container run as root user by default. To avoid use root user we can add
configuration in Dockerfile to build a container image.
Figure 4 presented an example how to use non-root permission in
Dockerfile.

7
Figure 4. An example using non-root permission
3.3 Credentials in container
Your application might need a credentials to interactive with other services
or applications. Figure 5 shows a bad practices to store credentials in
container. The attacker can get those credentials without your approval
once your container compromised.
Figure 5. An example using credentials

8
You can use container orchestration to pass credentials to container avoid
hard code credentials in container level.
Most of AWS services provide pass credentials via a secure way. For
example, Amazon Elastic Container Service (ECS) provide using AWS
Systems Manager Parameter Store to expose credentials to container.
Figure 6 presented an example to use AWS Systems Manager Parameter
Store expose credentials to AWS Batch container
Figure 6. AWS Batch secret configuration
Figure 7 presented an example to use Kubernetes Secret inject credentials
to container

9
Figure 7. Kubernetes secret configuration
3.4 Least privilege in container orchestration
Kubernetes provide Security Context configuration to let you defines
privilege and access control settings for a Pod or Container.
Figure 8 presented an example to use Kubernetes security context define
least privilege for a container.

10
Figure 8. Kubernetes security context configuration
For accessing AWS services in Kubernetes, you can define a least
privilege in Service Account.
Figure 9 presented an AWS IAM policy to restrict access a specific S3
bucket.

11
Figure 9. AWS IAM policy for accessing specific S3 bucket
Figure 10 presented an AWS IAM role for Amazon Elastic Kubernetes
Service (EKS). Using this IAM role configuration to let your EKS cluster
assume via EKS OICD. Any access permissions for AWS services can be
definied as an IAM policy attached to this role.

12
Figure 10. AWS IAM role for Amazon Elastic Kubernetes Service (EKS)
Figure 11 presented an example to use a Service Account for a container
to restrict only specific S3 bucket can be accessed.

13
Figure 11. Using Service Account in Kubernetes

14
4. Container orchestration security
Take Kubernetes as an example, Kubernetes release new version
quarterly. Those releases include CVE security patch as well.
Keep update latest Kubernetes version to your production environment with
fully protection capacity.
In AWS cloud, you can use Amazon Elastic Container Service (ECS) or
Amazon Elastic Kubernetes Service (EKS) as container orchestration.
Please visit below link for latest release version information of ECS and
EKS:
1. Release of Amazon Elastic Container Service (ECS)
2. Release of Amazon Elastic Kubernetes Service (EKS)

15
5. Container scanning via Amazon Elastic
Container Registry Scan
What is Container Scanning?
Container scanning, or container image scanning, is the process and
scanning tools used to identify vulnerabilities within containers and their
components. It’s key to container security and enables developers and
cybersecurity teams to fix security threats in containerized applications
before deployment. (Defined by Snyk)
A famous open-source tool for vulnerability static analysis in containers
called Trivy can help you implement container scanning.
In AWS cloud you don’t have to establish infrastructure resources for
container scanning. Amazon Elastic Container Registry (ECR) provide
native container scanning feature without any infrastructure establish.
Container scanning is disabled by default, you need to enable container
scan for your Elastic Container Registry.
There two kind of scan types in ECR: Basic scanning and Enhanced
scanning.
Basic scanning: There is no additional cost for basic scanning. It uses the
Common Vulnerabilities and Exposures (CVEs) database from the open-
source Clair project to scan your container image.
Enhanced scanning: Enhanced scanning is an integration with Amazon
Inspector which provides vulnerability scanning for your container images.
Your container images are scanned for both operating systems and
programing language package vulnerabilities. There is additional cost for
enhance scanning, please see the pricing model of Amazon Inspector.
Figure 12 presented a vulnerability finding list scanned via ECR basic
scanning. There are 6 severity rating in the list. Every CVE number has a
hyperlink page to let you know the detail information include package
name, description, fixed version, etc., please see Figure 13 as an example.

16
Figure 12. A vulnerability list of container image scanned via ECR basic scanning
Figure 13. CVE information page
Follow the fixed version information provided by CVE page to patch the
package version in your container.

17
6. Container scanning via Amazon Inspector
Amazon Inspector is an automated vulnerability management service that
continually scans Amazon Elastic Compute Cloud (EC2), AWS Lambda
functions, and container workloads for software vulnerabilities and
unintended network exposure.
As section 5 mentioned Amazon Inspector provide ECR Enhanced
scanning for both operating systems and programing language package
vulnerabilities.
When enable Amazon Inspector your ECR repository will set to Enhanced
scanning with Continuously scan mode. You can change the scan mode
to Lifetime (continuously), 180 Day, and 30 Day in Amazon Inspector -
ECR re-scan duration configuration.
Figure 14 presented a Dockerfile with log4j package vulnerability impact
version. Use this Dockerfile to build a container image and scan software
vulnerability via Amazon Inspector.
Figure 14. Dockerfile to build a container image with log4j package vulnerability impact version
Figure 15 presented the container scan report of a log4j package
vulnerability impact container image via Amazon Inspector. It provides
different severity rating for you same as ECR – basic scan type.
In the finding list, you can see a lot log4j package vulnerabilities. Pick a
critical issue as example.

18
Figure 16 presented the detail information of this vulnerability issue. In this
page you can see the vulnerability issue is related with what CVE number
and which fixed package version number. That information can help you to
fix this vulnerability.
Figure 15. Amazon Inspector container scan finding report

19
Figure 16. Detail information of a vulnerability issue

20
7. Implement security patch in container
In section 6 found a container contain log4j package vulnerability with
version 2.14.1. From the information of vulnerability issue page, this CVE
(CVE-2021-44228) is fixed in log4j package version 2.16.0.
Let’s update the log4j to latest version 2.19.0 in Dockerfile (Figure 17) and
build a new container push to ECR registry. Amazon Inspector will scan the
new container automatically after pushing container to ECR registry.
Figure 17. Patching log4j package in Dockerfile
The new finding report of Amazon Inspector presented in Figure 18. The
result show that CRITICAL, HIGH, and MEDIUM CVE issues have been
fixed by updating log4j package to version 2.19.0.
In this case we use a log4j vulnerability package as an example to show
how to implement a security patch in container image. Using this approach
to update your container image with latest CVE patching.
Keep patching your container image as a best practice to gain maximum
protection capacity.

21
Figure 18. Amazon Inspector container scan finding report after log4j package patching

Secure_Container_Workload.pdf

Recommended

Recommended

More Related Content

Similar to Secure_Container_Workload.pdf

Similar to Secure_Container_Workload.pdf (20)

Recently uploaded

Recently uploaded (20)

Secure_Container_Workload.pdf