Search the Community

Read this quick guide to the types of vulnerabilities that affect containers. The post What Makes Containers Vulnerable? appeared first on Mend. The post What Makes Containers Vulnerable? appeared first on Security Boulevard. View the full article

Containerization helped drastically improve the security of applications by providing engineers with greater control over the runtime environment of their applications. However, a significant time investment is required to maintain the security posture of those applications, given the daily discovery of new vulnerabilities as well as regular releases of languages and frameworks. The concept of “distroless” images offers the promise of greatly reducing the time needed to keep applications secure by eliminating most of the software contained in typical container images. This approach also reduces the amount of time teams spend remediating vulnerabilities, allowing them to focus only on the software they are using. In this article, we explain what makes an image distroless, describe tools that make the creation of distroless images practical, and discuss whether distroless images live up to their potential. What’s a distro? A Linux distribution is a complete operating system built around the Linux kernel, comprising a package management system, GNU tools and libraries, additional software, and often a graphical user interface. Common Linux distributions include Debian, Ubuntu, Arch Linux, Fedora, Red Hat Enterprise Linux, CentOS, and Alpine Linux (which is more common in the world of containers). These Linux distributions, like most Linux distros, treat security seriously, with teams working diligently to release frequent patches and updates to known vulnerabilities. A key challenge that all Linux distributions must face involves the usability/security dilemma. On its own, the Linux kernel is not very usable, so many utility commands are included in distributions to cover a large array of use cases. Having the right utilities included in the distribution without having to install additional packages greatly improves a distro’s usability. The downside of this increase in usability, however, is an increased attack surface area to keep up to date. A Linux distro must strike a balance between these two elements, and different distros have different approaches to doing so. A key aspect to keep in mind is that a distro that emphasizes usability is not “less secure” than one that does not emphasize usability. What it means is that the distro with more utility packages requires more effort from its users to keep it secure. Multi-stage builds Multi-stage builds allow developers to separate build-time dependencies from runtime ones. Developers can now start from a full-featured build image with all the necessary components installed, perform the necessary build step, and then copy only the result of those steps to a more minimal or even an empty image, called “scratch”. With this approach, there’s no need to clean up dependencies and, as an added bonus, the build stages are also cacheable, which can considerably reduce build time. The following example shows a Go program taking advantage of multi-stage builds. Because the Golang runtime is compiled into the binary, only the binary and root certificates need to be copied to the blank slate image. FROM golang:1.21.5-alpine as build WORKDIR / COPY go.* . RUN go mod download COPY . . RUN go build -o my-app FROM scratch COPY --from=build /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ca-certificates.crt COPY --from=build /my-app /usr/local/bin/my-app ENTRYPOINT ["/usr/local/bin/my-app"] BuildKit BuildKit, the current engine used by docker build, helps developers create minimal images thanks to its extensible, pluggable architecture. It provides the ability to specify alternative frontends (with the default being the familiar Dockerfile) to abstract and hide the complexity of creating distroless images. These frontends can accept more streamlined and declarative inputs for builds and can produce images that contain only the software needed for the application to run. The following example shows the input for a frontend for creating Python applications called mopy by Julian Goede. #syntax=cmdjulian/mopy apiVersion: v1 python: 3.9.2 build-deps: - libopenblas-dev - gfortran - build-essential envs: MYENV: envVar1 pip: - numpy==1.22 - slycot - ./my_local_pip/ - ./requirements.txt labels: foo: bar fizz: ${mopy.sbom} project: my-python-app/ So, is your image really distroless? Thanks to new tools for creating container images like multi-stage builds and BuildKit, it is now a lot more practical to create images that only contain the required software and its runtime dependencies. However, many images claiming to be distroless still include a shell (usually Bash) and/or BusyBox, which provides many of the commands a Linux distribution does — including wget — that can leave containers vulnerable to Living off the land (LOTL) attacks. This raises the question, “Why would an image trying to be distroless still include key parts of a Linux distribution?” The answer typically involves container initialization. Developers often have to make their applications configurable to meet the needs of their users. Most of the time, those configurations are not known at build time so they need to be configured at run time. Often, these configurations are applied using shell initialization scripts, which in turn depend on common Linux utilities such as sed, grep, cp, etc. When this is the case, the shell and utilities are only needed for the first few seconds of the container’s lifetime. Luckily, there is a way to create true distroless images while still allowing initialization using tools available from most container orchestrators: init containers. Init containers In Kubernetes, an init container is a container that starts and must complete successfully before the primary container can start. By using a non-distroless container as an init container that shares a volume with the primary container, the runtime environment and application can be configured before the application starts. The lifetime of that init container is short (often just a couple seconds), and it typically doesn’t need to be exposed to the internet. Much like multi-stage builds allow developers to separate the build-time dependencies from the runtime dependencies, init containers allow developers to separate initialization dependencies from the execution dependencies. The concept of init container may be familiar if you are using relational databases, where an init container is often used to perform schema migration before a new version of an application is started. Kubernetes example Here are two examples of using init containers. First, using Kubernetes: apiVersion: v1 kind: Pod metadata: name: kubecon-postgress-pod labels: app.kubernetes.io/name: KubeConPostgress spec: containers: - name: postgress image: laurentgoderre689/postgres-distroless securityContext: runAsUser: 70 runAsGroup: 70 volumeMounts: - name: db mountPath: /var/lib/postgresql/data/ initContainers: - name: init-postgress image: postgres:alpine3.18 env: - name: POSTGRES_PASSWORD valueFrom: secretKeyRef: name: kubecon-postgress-admin-pwd key: password command: ['docker-ensure-initdb.sh'] volumeMounts: - name: db mountPath: /var/lib/postgresql/data/ volumes: - name: db emptyDir: {} - - - > kubectl apply -f pod.yml && kubectl get pods pod/kubecon-postgress-pod created NAME READY STATUS RESTARTS AGE kubecon-postgress-pod 0/1 Init:0/1 0 0s > kubectl get pods NAME READY STATUS RESTARTS AGE kubecon-postgress-pod 1/1 Running 0 10s Docker Compose example The init container concept can also be emulated in Docker Compose for local development using service dependencies and conditions. services: db: image: laurentgoderre689/postgres-distroless user: postgres volumes: - pgdata:/var/lib/postgresql/data/ depends_on: db-init: condition: service_completed_successfully db-init: image: postgres:alpine3.18 environment: POSTGRES_PASSWORD: example volumes: - pgdata:/var/lib/postgresql/data/ user: postgres command: docker-ensure-initdb.sh volumes: pgdata: - - - > docker-compose up [+] Running 4/0 ✔ Network compose_default Created ✔ Volume "compose_pgdata" Created ✔ Container compose-db-init-1 Created ✔ Container compose-db-1 Created Attaching to db-1, db-init-1 db-init-1 | The files belonging to this database system will be owned by user "postgres". db-init-1 | This user must also own the server process. db-init-1 | db-init-1 | The database cluster will be initialized with locale "en_US.utf8". db-init-1 | The default database encoding has accordingly been set to "UTF8". db-init-1 | The default text search configuration will be set to "english". db-init-1 | [...] db-init-1 exited with code 0 db-1 | 2024-02-23 14:59:33.191 UTC [1] LOG: starting PostgreSQL 16.1 on aarch64-unknown-linux-musl, compiled by gcc (Alpine 12.2.1_git20220924-r10) 12.2.1 20220924, 64-bit db-1 | 2024-02-23 14:59:33.191 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432 db-1 | 2024-02-23 14:59:33.191 UTC [1] LOG: listening on IPv6 address "::", port 5432 db-1 | 2024-02-23 14:59:33.194 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432" db-1 | 2024-02-23 14:59:33.196 UTC [9] LOG: database system was shut down at 2024-02-23 14:59:32 UTC db-1 | 2024-02-23 14:59:33.198 UTC [1] LOG: database system is ready to accept connections As demonstrated by the previous example, an init container can be used alongside a container to remove the need for general-purpose software and allow the creation of true distroless images. Conclusion This article explained how Docker build tools allow for the separation of build-time dependencies from run-time dependencies to create “distroless” images. For example, using init containers allows developers to separate the logic needed to configure a runtime environment from the environment itself and provide a more secure container. This approach also helps teams focus their efforts on the software they use and find a better balance between security and usability. Learn more Subscribe to the Docker Newsletter. Get the latest release of Docker Desktop. Vote on what’s next! Check out our public roadmap. Have questions? The Docker community is here to help. New to Docker? Get started. View the full article

The post How to Setup Apache Web Server in a Docker Container first appeared on Tecmint: Linux Howtos, Tutorials & Guides .If you are a Linux system administrator who provides support for developers, chances are you’ve heard of Docker. If not, this software solution will make The post How to Setup Apache Web Server in a Docker Container first appeared on Tecmint: Linux Howtos, Tutorials & Guides.View the full article

In the ever-evolving software delivery landscape, containerization has emerged as a transformative force, reshaping how organizations build, test, deploy, and manage their applications. Whether you are maintaining a monolithic legacy system, navigating the complexities of Service-Oriented Architecture (SOA), or orchestrating your digital strategy around application programming interfaces (APIs), containerization offers a pathway to increased efficiency, resilience, and agility. In this post, we’ll debunk the myth that containerization is solely the domain of microservices by exploring its applicability and advantages across different architectural paradigms. Containerization across architectures Although containerization is commonly associated with microservices architecture because of its agility and scalability, the potential extends far beyond, offering compelling benefits to a variety of architectural styles. From the tightly integrated components of monolithic applications to the distributed nature of SOA and the strategic approach of API-led connectivity, containerization stands as a universal tool, adaptable and beneficial across the board. Beyond the immediate benefits of improved resource utilization, faster deployment cycles, and streamlined maintenance, the true value of containerization lies in its ability to ensure consistent application performance across varied environments. This consistency is a cornerstone for reliability and efficiency, pivotal in today’s fast-paced software delivery demands. Here, we will provide examples of how this technology can be a game-changer for your digital strategy, regardless of your adopted style. Through this exploration, we invite technology leaders and executives to broaden their perspective on containerization, seeing it not just as a tool for one architectural approach but as a versatile ally in the quest for digital excellence. 1. Event-driven architecture Event-driven architecture (EDA) represents a paradigm shift in how software components interact, pivoting around the concept of events — such as state changes or specific action occurrences — as the primary conduit for communication. This architectural style fosters loose coupling, enabling components to operate independently and react asynchronously to events, thereby augmenting system flexibility and agility. EDA’s intrinsic support for scalability, by allowing components to address fluctuating workloads independently, positions it as an ideal candidate for handling dynamic system demands. Within the context of EDA, containerization emerges as a critical enabler, offering a streamlined approach to encapsulate applications alongside their dependencies. This encapsulation guarantees that each component of an event-driven system functions within a consistent, isolated environment — a crucial factor when managing components with diverse dependency requirements. Containers’ scalability becomes particularly advantageous in EDA, where fluctuating event volumes necessitate dynamic resource allocation. By deploying additional container instances in response to increased event loads, systems maintain high responsiveness levels. Moreover, containerization amplifies the deployment flexibility of event-driven components, ensuring consistent event generation and processing across varied infrastructures (Figure 1). This adaptability facilitates the creation of agile, scalable, and portable architectures, underpinning the deployment and management of event-driven components with a robust, flexible infrastructure. Through containerization, EDA systems achieve enhanced operational efficiency, scalability, and resilience, embodying the principles of modern, agile application delivery. Figure 1: Event-driven architecture. 2. API-led architecture API-led connectivity represents a strategic architectural approach focused on the design, development, and management of APIs to foster seamless connectivity and data exchange across various systems, applications, and services within an organization (Figure 2). This methodology champions a modular and scalable framework ideal for the modern digital enterprise. The principles of API-led connectivity — centering on system, process, and experience APIs — naturally harmonize with the benefits of containerization. By encapsulating each API within its container, organizations can achieve unparalleled modularity and scalability. Containers offer an isolated runtime environment for each API, ensuring operational independence and eliminating the risk of cross-API interference. This isolation is critical, as it guarantees that modifications or updates to one API can proceed without adversely affecting others, which is a cornerstone of maintaining a robust API-led ecosystem. Moreover, the dual advantages of containerization — ensuring consistent execution environments and enabling easy scalability — align perfectly with the goals of API-led connectivity. This combination not only simplifies the deployment and management of APIs across diverse environments but also enhances the resilience and flexibility of the API infrastructure. Together, API-led connectivity and containerization empower organizations to develop, scale, and manage their API ecosystems more effectively, driving efficiency and innovation in application delivery. Figure 2: API-led architecture. 3. Service-oriented architecture Service-oriented architecture (SOA) is a design philosophy that emphasizes the use of discrete services within an architecture to provide business functionalities. These services communicate through well-defined interfaces and protocols, enabling interoperability and facilitating the composition of complex applications from independently developed services. SOA’s focus on modularity and reusability makes it particularly amenable to the benefits offered by containerization. Containerization brings a new dimension of flexibility and efficiency to SOA by encapsulating these services into containers. This encapsulation provides an isolated environment for each service, ensuring consistent execution regardless of the deployment environment. Such isolation is crucial for maintaining the integrity and availability of services, particularly in complex, distributed architectures where services must communicate across different platforms and networks. Moreover, containerization enhances the scalability and manageability of SOA-based systems. Containers can be dynamically scaled to accommodate varying loads, enabling organizations to respond swiftly to changes in demand. This scalability, combined with the ease of deployment and rollback provided by container orchestration platforms, supports the agile delivery and continuous improvement of services. The integration of containerization with SOA essentially results in a more resilient, scalable, and manageable architecture. It enables organizations to leverage the full potential of SOA by facilitating faster deployment, enhancing performance, and simplifying the lifecycle management of services. Together, SOA and containerization create a powerful framework for building flexible, future-proof applications that can adapt to the evolving needs of the business. 4. Monolithic applications Contrary to common perceptions, monolithic applications stand to gain significantly from containerization. This technology can encapsulate the full application stack — including the core application, its dependencies, libraries, and runtime environment within a container. This encapsulation ensures uniformity across various stages of the development lifecycle, from development and testing to production, effectively addressing the infamous ‘it works on my machine’ challenge. Such consistency streamlines the deployment process and simplifies scaling efforts, which is particularly beneficial for applications that need to adapt quickly to changing demands. Moreover, containerization fosters enhanced collaboration among development teams by standardizing the operational environment, thereby minimizing discrepancies that typically arise from working in divergent development environments. This uniformity is invaluable in accelerating development cycles and improving product reliability. Perhaps one of the most strategic benefits of containerization for monolithic architectures is the facilitation of a smoother transition to microservices. By containerizing specific components of the monolith, organizations can incrementally decompose their application into more manageable, loosely coupled microservices. This approach not only mitigates the risks associated with a full-scale migration but also allows teams to gradually adapt to microservices’ architectural patterns and principles. Containerization presents a compelling proposition for monolithic applications, offering a pathway to modernization that enhances deployment efficiency, operational consistency, and the flexibility to evolve toward a microservices-oriented architecture. Through this lens, containerization is not just a tool for new applications but a bridge that allows legacy applications to step into the future of software development. Conclusion The journey of modern software development, with its myriad architectural paths, is markedly enhanced by the adoption of containerization. This technology transcends architectural boundaries, bringing critical advantages such as isolation, scalability, and portability to the forefront of application delivery. Whether your environment is monolithic, service-oriented, event-driven, or API-led, containerization aligns perfectly with the ethos of modern, distributed, and cloud-native applications. By embracing the adaptability and transformative potential of containerization, you can open your architectures to a future where agility, efficiency, and resilience are not just aspirations but achievable realities. Begin your transformative journey with Docker Desktop today and redefine what’s possible within the bounds of your existing architectural framework. Learn more How to Stuff Monolithic Applications Into a Container (DockerCon 2023) Subscribe to the Docker Newsletter. Explore Docker Desktop. Join the Docker community. Skill up with Docker training. View the full article

I have task to run container (on my azure vm - linux) from nahidupa/crash:latest image and before fix all the problems. So when i try to run container i have error ~$ docker run -it nahidupa/crash:latest Unhandled exception. System.IO.FileNotFoundException: Could not find file '/c:\notes.txt'. File name: '/c:\notes.txt' at Interop.ThrowExceptionForIoErrno(ErrorInfo errorInfo, String path, Boolean isDirectory, Func`2 errorRewriter) at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String path, OpenFlags flags, Int32 mode) at System.IO.FileStream.OpenHandle(FileMode mode, FileShare share, FileOptions options) at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options) at System.IO.StreamReader.ValidateArgsAndOpenPath(String path, Encoding encoding, Int32 bufferSize) at System.IO.StreamReader..ctor(String path, Encoding encoding) at System.IO.File.ReadLines(String path) at crash.Program.Main(String[] args) in /Users/nahidul/RiderProjects/crash/crash/Program.cs:line 9 I tried to connect to container interactively and have this files root@8075cccbb894:/# ls Dockerfile bin crash.csproj etc lib media notes.txt opt root sbin sys usr Program.cs boot dev home lib64 mnt obj proc run srv tmp var nano Program.cs using System; namespace crash { class Program { static void Main(string[] args) { System.IO.File.ReadLines("c:\\notes.txt"); } } } made changes in this file but dont know what to do next. I dont have a lot experience in docker so maybe you can help me.

Author: Kevin Hannon (Red Hat) A common issue in running/operating Kubernetes clusters is running out of disk space. When the node is provisioned, you should aim to have a good amount of storage space for your container images and running containers. The container runtime usually writes to /var. This can be located as a separate partition or on the root filesystem. CRI-O, by default, writes its containers and images to /var/lib/containers, while containerd writes its containers and images to /var/lib/containerd. In this blog post, we want to bring attention to ways that you can configure your container runtime to store its content separately from the default partition. This allows for more flexibility in configuring Kubernetes and provides support for adding a larger disk for the container storage while keeping the default filesystem untouched. One area that needs more explaining is where/what Kubernetes is writing to disk. Understanding Kubernetes disk usage Kubernetes has persistent data and ephemeral data. The base path for the kubelet and local Kubernetes-specific storage is configurable, but it is usually assumed to be /var/lib/kubelet. In the Kubernetes docs, this is sometimes referred to as the root or node filesystem. The bulk of this data can be categorized into: ephemeral storage logs and container runtime This is different from most POSIX systems as the root/node filesystem is not / but the disk that /var/lib/kubelet is on. Ephemeral storage Pods and containers can require temporary or transient local storage for their operation. The lifetime of the ephemeral storage does not extend beyond the life of the individual pod, and the ephemeral storage cannot be shared across pods. Logs By default, Kubernetes stores the logs of each running container, as files within /var/log. These logs are ephemeral and are monitored by the kubelet to make sure that they do not grow too large while the pods are running. You can customize the log rotation settings for each node to manage the size of these logs, and configure log shipping (using a 3rd party solution) to avoid relying on the node-local storage. Container runtime The container runtime has two different areas of storage for containers and images. read-only layer: Images are usually denoted as the read-only layer, as they are not modified when containers are running. The read-only layer can consist of multiple layers that are combined into a single read-only layer. There is a thin layer on top of containers that provides ephemeral storage for containers if the container is writing to the filesystem. writeable layer: Depending on your container runtime, local writes might be implemented as a layered write mechanism (for example, overlayfs on Linux or CimFS on Windows). This is referred to as the writable layer. Local writes could also use a writeable filesystem that is initialized with a full clone of the container image; this is used for some runtimes based on hypervisor virtualisation. The container runtime filesystem contains both the read-only layer and the writeable layer. This is considered the imagefs in Kubernetes documentation. Container runtime configurations CRI-O CRI-O uses a storage configuration file in TOML format that lets you control how the container runtime stores persistent and temporary data. CRI-O utilizes the storage library. Some Linux distributions have a manual entry for storage (man 5 containers-storage.conf). The main configuration for storage is located in /etc/containers/storage.conf and one can control the location for temporary data and the root directory. The root directory is where CRI-O stores the persistent data. [storage] # Default storage driver driver = "overlay" # Temporary storage location runroot = "/var/run/containers/storage" # Primary read/write location of container storage graphroot = "/var/lib/containers/storage" graphroot Persistent data stored from the container runtime If SELinux is enabled, this must match the /var/lib/containers/storage runroot Temporary read/write access for container Recommended to have this on a temporary filesystem Here is a quick way to relabel your graphroot directory to match /var/lib/containers/storage: semanage fcontext -a -e /var/lib/containers/storage <YOUR-STORAGE-PATH> restorecon -R -v <YOUR-STORAGE-PATH> containerd The containerd runtime uses a TOML configuration file to control where persistent and ephemeral data is stored. The default path for the config file is located at /etc/containerd/config.toml. The relevant fields for containerd storage are root and state. root The root directory for containerd metadata Default is /var/lib/containerd Root also requires SELinux labels if your OS requires it state Temporary data for containerd Default is /run/containerd Kubernetes node pressure eviction Kubernetes will automatically detect if the container filesystem is split from the node filesystem. When one separates the filesystem, Kubernetes is responsible for monitoring both the node filesystem and the container runtime filesystem. Kubernetes documentation refers to the node filesystem and the container runtime filesystem as nodefs and imagefs. If either nodefs or the imagefs are running out of disk space, then the overall node is considered to have disk pressure. Kubernetes will first reclaim space by deleting unusued containers and images, and then it will resort to evicting pods. On a node that has a nodefs and an imagefs, the kubelet will garbage collect unused container images on imagefs and will remove dead pods and their containers from the nodefs. If there is only a nodefs, then Kubernetes garbage collection includes dead containers, dead pods and unused images. Kubernetes allows more configurations for determining if your disk is full. The eviction manager within the kubelet has some configuration settings that let you control the relevant thresholds. For filesystems, the relevant measurements are nodefs.available, nodefs.inodesfree, imagefs.available, and imagefs.inodesfree. If there is not a dedicated disk for the container runtime then imagefs is ignored. Users can use the existing defaults: memory.available < 100MiB nodefs.available < 10% imagefs.available < 15% nodefs.inodesFree < 5% (Linux nodes) Kubernetes allows you to set user defined values in EvictionHard and EvictionSoft in the kubelet configuration file. EvictionHard defines limits; once these limits are exceeded, pods will be evicted without any grace period. EvictionSoft defines limits; once these limits are exceeded, pods will be evicted with a grace period that can be set per signal. If you specify a value for EvictionHard, it will replace the defaults. This means it is important to set all signals in your configuration. For example, the following kubelet configuration could be used to configure eviction signals and grace period options. apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration address: "192.168.0.8" port: 20250 serializeImagePulls: false evictionHard: memory.available: "100Mi" nodefs.available: "10%" nodefs.inodesFree: "5%" imagefs.available: "15%" imagefs.inodesFree: "5%" evictionSoft: memory.available: "100Mi" nodefs.available: "10%" nodefs.inodesFree: "5%" imagefs.available: "15%" imagefs.inodesFree: "5%" evictionSoftGracePeriod: memory.available: "1m30s" nodefs.available: "2m" nodefs.inodesFree: "2m" imagefs.available: "2m" imagefs.inodesFree: "2m" evictionMaxPodGracePeriod: 60s Problems The Kubernetes project recommends that you either use the default settings for eviction or you set all the fields for eviction. You can use the default settings or specify your own evictionHard settings. If you miss a signal, then Kubernetes will not monitor that resource. One common misconfiguration administrators or users can hit is mounting a new filesystem to /var/lib/containers/storage or /var/lib/containerd. Kubernetes will detect a separate filesystem, so you want to make sure to check that imagefs.inodesfree and imagefs.available match your needs if you've done this. Another area of confusion is that ephemeral storage reporting does not change if you define an image filesystem for your node. The image filesystem (imagefs) is used to store container image layers; if a container writes to its own root filesystem, that local write doesn't count towards the size of the container image. The place where the container runtime stores those local modifications is runtime-defined, but is often the image filesystem. If a container in a pod is writing to a filesystem-backed emptyDir volume, then this uses space from the nodefs filesystem. The kubelet always reports ephemeral storage capacity and allocations based on the filesystem represented by nodefs; this can be confusing when ephemeral writes are actually going to the image filesystem. Future work To fix the ephemeral storage reporting limitations and provide more configuration options to the container runtime, SIG Node are working on KEP-4191. In KEP-4191, Kubernetes will detect if the writeable layer is separated from the read-only layer (images). This would allow us to have all ephemeral storage, including the writeable layer, on the same disk as well as allowing for a separate disk for images. Getting involved If you would like to get involved, you can join Kubernetes Node Special-Interest-Group (SIG). If you would like to share feedback, you can do so on our #sig-node Slack channel. If you're not already part of that Slack workspace, you can visit https://slack.k8s.io/ for an invitation. Special thanks to all the contributors who provided great reviews, shared valuable insights or suggested the topic idea. Peter Hunt Mrunal Patel Ryan Phillips Gaurav Singh View the full article

Google Kubernetes Engine (GKE) traces its roots back to Google’s development of Borg in 2004, a Google internal system managing clusters and applications. In 2014, Google introduced Kubernetes, an open-source platform based on Borg’s principles, gaining rapid popularity for automating containerized application deployment. In 2015, Google launched GKE, a managed Kubernetes service on Google Cloud Platform (GCP), streamlining infrastructure management for users. Over the years, GKE saw substantial growth, introducing Autopilot mode in 2017 and surpassing 2 million managed clusters by 2019. Throughout 2020 and 2021, GKE continued evolving with features like Workload Identity and Anthos Config Management, aiding in access management and configurations. In 2022, GKE maintained its status as a leading managed Kubernetes platform, introducing innovations like Anthos Service Mesh and Anthos Multi-Cluster Ingress. GKE’s trajectory underscores the significance of containerization and cloud-native tech, poised to further empower the development, deployment, and management of modern applications amidst growing industry adoption. Ubuntu can be used as the base operating system for GKE nodes, and GKE can be used to deploy and manage containerized applications on Ubuntu nodes. Here are some of the benefits of using Ubuntu and GKE together: Flexibility: Ubuntu can be used with a variety of Kubernetes distributions, so developing teams will have a standardized experience across multiple cloud, such as Azure Kubernetes Service (AKS) and Amazon EKS.Secure. Timely updates and patches, building on Ubuntu’s security track record.Stable. Long-term support with a consistent, predictable lifecycle and support commitment. Each GKE version has a customized version of Ubuntu that support its latest features.Seamless. Developer-friendly, smooth experience from development to production.Small. Ultra-small, resource-efficient, yet robust images with chiselled (distroless) Ubuntu. Let’s go through the steps you need to deploy Ubuntu nodes in GKE. In Google Cloud Console, locate Kubernetes Engine: In “Clusters”, click CREATE: Choose “Standard: You manage your cluster” in the pop-up window: In the left of the console, click “default-pool”: Click “Nodes”: Find “Ubuntu with containerd (ubuntu_containerd)” in “Image type” drop-down menu: Choose “Ubuntu with containerd (ubuntu_containerd)” and Click “CREATE” at the bottom: Once the cluster is running, you can check “OS image” in the “Node details”: View the full article

In a Kubernetes environment, you encounter a situation where a service’s configuration is not consistent across multiple clusters. What common configuration element could be the source of this issue? 1. Pod resource requests and limits 2. Container image tags 3. Ingress controller settings 4. Service account permissions 5. Node affinity rules View the full article

The world of application integration is witnessing a transformative shift, one that is redefining the landscape of software development and deployment. This transformation is underpinned by the rise of containerization technologies, which encapsulate applications and their dependencies within isolated, consistent environments. Historically, application integration has faced myriad challenges, from compatibility issues between different systems to the complexities of scaling applications in response to fluctuating demands. The introduction of containers has emerged as a solution to these challenges, offering a paradigm that enhances agility, scalability, and efficiency. View the full article

Amazon Elastic Kubernetes Service (Amazon EKS) with AWS Fargate provides serverless compute for containerized workloads that run on Kubernetes. By eliminating the need for infrastructure management with AWS Fargate, customers can avoid the operational overhead of scaling, patching, and securing instances. AWS Fargate provides a secure and a controlled environment for container execution. Consequently, customers are not allowed to extend extra privileges to containers in operation. As a result, traditional methods for enhancing visibility and ensuring container runtime security will not work. This post demonstrates the use of Aqua’s Cloud Native Security Platform on AWS Fargate to deliver runtime security without requiring added privileges. Aqua’s platform is compatible with containers deployed on various infrastructures, such as Amazon Elastic Container Service (Amazon ECS) and Amazon EKS.This post will focus on Amazon EKS.. The container runtime security element of Aqua’s Platform, the MicroEnforcer, is an agent that can be added to Kubernetes pods and can run unprivileged on AWS Fargate. Aqua’s Platform injects the MicroEnforcer into a Kubernetes pod and enforces run-time security, without the user having to make changes to the application or their deployment specifications. These run-time protection capabilities are delivered as part of comprehensive cloud-native security platform, spanning vulnerability management, cloud security posture management, supply chain security, Kubernetes security, assurance, and cloud-integrated storage (CIS) benchmarking. Aqua Security is an AWS Advanced Technology Partner with the AWS Containers Competency. They provide highly integrated security controls that customers use to build full code-to-production security across their continuous integration/continuous deployment (CI/CD) pipeline, with an orchestration layer and runtime environments... View the full article

How do you monitor a container workload running on ECS (Elastic Container Service) and Fargate with on-board resources? Here are the prioritized aspects when it comes to monitoring containers on AWS... Event-driven monitoring with EventBridge Monitoring entry points like ALB, SQS, and Kinesis Monitoring inter-service communication (Service Connect) Observing container utilization Collecting and analyzing container logs View the full article

Containerization is rapidly gaining popularity for becoming the sure-shot way to deploy and manage applications. And Docker has been the ultimate poster boy of this technology for the past few years. Docker is a widely adopted containerization platform that allows developers to package applications and their dependencies into a single container image. It simplifies application deployment and scaling, making it popular in various industries. View the full article

Did you know you can containerize your Spring Boot applications to start up in milliseconds, without compromising on throughput, memory, development-production parity, or Java language features? And with little or no refactoring of the application code? Here’s how with Open Liberty 23.0.0.10-beta. The InstantOn capability in the Open Liberty runtime uses the IBM Semeru JDK and a Linux technology called Checkpoint/Restore in Userspace (CRIU) to take a checkpoint, or a point-in-time snapshot, of the application process. This checkpoint can then be restored very quickly to bring the application process back into the state it was in when the checkpoint was taken. The application can be restored multiple times because Open Liberty and the Semeru JDK preserve the uniqueness of each restored process in containers. Each restored application process runs without first having to go through the whole startup sequence, saving up to 90% of startup time (depending on your application). InstantOn requires very little modification of your Java application to make this improvement happen. View the full article

Docker is an open-source platform for building, shipping, and running applications in containers. Containers provide a lightweight and portable way to package and deploy software, making it easier to move applications between environments and platforms. By using Docker to containerize your database application, you can ensure that it runs consistently across different environments, making it easier to deploy and manage. In this tutorial, we will walk through the process of containerizing a MySQL database using Docker and connecting to it using DbVisualizer. We will start with a simple example and then move on to more complex scenarios, including using Docker Compose to orchestrate multiple containers and using environment variables to configure our container. View the full article

Today, AWS announces the availability of AWS Fargate for Amazon ECS Windows containers in the AWS GovCloud (US) Regions. This feature simplifies the adoption of modern container technology for Amazon ECS customers by making it even easier to run their Windows containers on AWS. View the full article

We’re excited to share that Gartner has recognized Google as a Leader in the 2023 Gartner® Magic Quadrant™ for Container Management with Google Cloud being evaluated. Google was positioned highest in Ability to Execute of all vendors evaluated and we believe this validates the success of our mission to be the best place for customers anywhere to run containerized workloads. Gartner predicts that “by 2027, more than 90% of global organizations will be running containerized applications in production, which is a significant increase from fewer than 40% in 2021.” From our perspective, containers power today’s most innovative apps and businesses — and will unlock even greater business transformation and innovation in the years ahead. Our journey began in 2014 when we introduced Kubernetes and launched Google Kubernetes Engine (GKE), the first managed Kubernetes service in the world. GKE is the most scalable leading Kubernetes service available in the industry today. In 2019, we launched Cloud Run, the first platform to combine the benefits of containers and serverless. Today, Cloud Run provides one of the leading developer experiences of all cloud providers. In 2019, we also extended GKE to hybrid and multi-cloud environments with Anthos, and introduced Autopilot mode in GKE in 2021. This year, we expanded the reach of our container management platform to Google Distributed Cloud. Wherever our customers build and run containers, from Google Cloud to other clouds to the data center and the edge, we aim to deliver the most simple, comprehensive, secure, and reliable container platform for all workloads. Today, we continue our mission to help our customers modernize and transform their businesses with containers. At our flagship Google Cloud Next ‘23 conference, we introduced powerful new enhancements to our container management products, what we call “the next evolution of container platforms.” Key innovations include: GKE Enterprise, a new premium edition of GKE. GKE Enterprise builds on Google Cloud’s leadership in containers and Kubernetes, bringing together the best of GKE and Anthos into an integrated and intuitive container platform, with a unified console experience. Plus, GKE Enterprise includes hybrid and multi-cloud support, so you can run container workloads anywhere.Cloud TPU v5e support in GKE, for organizations developing the next generation of AI applications. We also announced general availability of both the A3 VM with NVIDIA H100 GPU and Cloud Storage Fuse for GKE.Duet AI in GKE and Cloud Run leverages the power of generative AI to drive productivity and velocity for customer container platform teams. With Duet AI specifically trained on our container management product documentation, customers can cut down on the time it takes to run and optimize containerized applications.Check out all the key container management innovations announced at Next ‘23 — from Kubernetes to AI — and how Google Cloud helps our customers improve efficiency, reliability, and security for their most important containerized workloads. We’ve come a long way since 2014, and we are thrilled to be recognized as a Leader for Container Management by Gartner. We are also grateful to our customers around the world who’ve placed their trust in our container management products. Here’s a small sampling: The BBC uses Cloud Run to handle dramatic traffic spikes, scale from 150-200 container instances to over 1,000 in under a minutes, and entertain over 498 million adults per week.Carrefour depends on both GKE and Cloud Run together to run new ecommerce apps.Equifax depends on GKE as the foundation of its global data fabric, analyzing 250 billion data points across 8 geographies and helping its customers around the world live their financial best.The 15 largest GKE customers are already using it to power their AI workloads. In fact, over the last year, the use of GPUs with GKE has doubled. Hear how grammarly, Lightricks, and character.ai work with GKE to build large AI models.We are honored to be a Leader in the 2023 Gartner® Magic Quadrant™ for Container Management, and look forward to continuing to innovate and partner with customers on their digital transformation journeys. Download the complimentary copy of the report: 2023 Gartner® Magic Quadrant™ for Container Management. Learn more about how organizations are transforming their businesses with Containers in Google Cloud.

Containerization has transformed software development and deployment, and Docker has been at the forefront of this revolution. Docker multi-stage builds are a powerful feature that can help you optimize your Docker images, reduce their size, and enhance your development and deployment workflows. In this comprehensive guide, we'll explore what Docker multi-stage builds are, why they are important, how to create them, when to use them, and more. Read More Here

Unlock the power of modern application development. Accelerate innovation, enhance performance, fortify security, and boost reliability while significantly reducing your TCO. Which containers or serverless service should I start with to modernize my existing or build new applications? There are two primary operating models for building, running, and modernizing code on AWS: Kubernetes and Serverless. […] View the full article

Introduction Many applications built today or modernized from monoliths are done so using microservice architectures. The microservice architecture makes applications easier to scale and faster to develop, which enables innovation and accelerating time-to-market for new features. In addition, microservices also provide lifecycle autonomy enabling applications to have independent build and deploy processes, which provides technological freedom such that they can be implemented in different programming languages and provide scaling flexibility to scale up or scale down independently based on workload utilization. While microservices provide a lot of flexibility, the process of building and deploying them, ensuring the right application versions, and required dependencies are used is a tedious process. This is where containers come in. Microservices can be packaged into a single lightweight and standalone executable artifact called container image that includes everything to run an application. This process of packaging a microservice into container image is called containerization. Containerization offers a lot of benefits, such as portability, which allow containers to be deployed to different infrastructures. It also offers fault isolation, which ensures that different containers are running as isolated process within their own user space in the host OS so that one container’s crash or failure wouldn’t impact the other and provide ease-of-management for deployment and version management. With the benefits that are offered via microservices and subsequent containerization, creation of container images have increased at a rapid scale. As the use of containerized applications continue to grow, it is important to ensure that your container images are optimized, secure, and reliable. Taking these tenets into account in this post, we discuss best practices for building better container images for use on Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), and other services. For the container image repositories, we focus on Amazon Elastic Container Registry (Amazon ECR). Building better images We’ll look at the following approaches to build better images. While this isn’t an exhaustive list, these topics provide a good base for your image builds, and you can adopt them as you wish. Walkthrough Use trusted images and source Using a base image from a trusted source can improve the security and reliability of your container. This is because you can be confident that the base image has been thoroughly tested and vetted. It can also reduce the burden of establishing provenance, because you only need to consider the packages and libraries that you include in your image, rather than the entire base image. Here is an example creating a Dockerfile using the official Python base image from the Amazon ECR repository. In fact, all of the Docker official images are available on Amazon ECR public gallery. Note: The code samples in the blog are for Docker. If you don’t have Docker, then please refer to Docker installation guide for information about how to install Docker on your particular operating system. Alternatively, you can also consider using Finch an open source client for container development. FROM public.ecr.aws/docker/library/python:slim # Install necessary packages RUN pip install flask COPY app.py /app/ ENTRYPOINT ["python", "/app/app.py"] Here’s another example of using latest version (as of the data of this post) of Amazon Linux image, which is a secure and lightweight Linux distribution provided by AWS. FROM public.ecr.aws/amazonlinux/amazonlinux:2023 It is important to keep images up-to-date by regularly updating to latest secure versions of the software and libraries included in the image. As new versions of the images get created, they should be explicitly tagged with versions such as v1, v2, rc_03122023, etc instead of tagging as latest. Using explicit tags instead of latest tag could prevent situations where the image with latest tag isn’t actually updated and instead gives a false appearance that the image contains the latest version of the application. If you’re confident in your automation, then vanity tags such as latest or prod might be acceptable to use, but avoiding them also reduces ambiguity. This can avoid confusion about which application version may actually being used. Once images are created, they can be pushed into the Amazon ECR repository for secure storage and highly available distribution. Amazon ECR encrypts data at rest and offers lifecycle management, replication, and caching features. Amazon ECR can also scan the images to help in identifying software vulnerabilities through Basic and Enhanced Scanning. Stored images from Amazon ECR can then be pulled and run by services such Amazon ECS, Amazon EKS, or other services and tools. Here is an example of using AWS Command Line Interface (AWS CLI) and Docker CLI to pull a versioned image from Amazon ECR. Step 1 – Authenticate your Docker client to the Amazon Linux Public registry. Authentication tokens are valid for 12 hours. For more information, see Private registry authentication. Alternatively, you can also use Amazon ECR Docker Credential Helper, which is a credential helper for the Docker daemon that makes it easier to use Amazon Elastic Container Registry. Amazon ECR Docker credential helper automatically gets credentials for Amazon ECR on docker push and docker pull. Note that this would only be required for Amazon ECR, but ECR Public doesn’t need authentication. $ aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws Step 2 – Pull the Amazon Linux container image using the docker pull command. To view the Amazon Linux container image on the Amazon ECR Public Gallery, see Amazon ECR Public Gallery – amazonlinux. docker pull public.ecr.aws/amazonlinux/amazonlinux:2023 Step 3 – Run the container locally. docker run -it public.ecr.aws/amazonlinux/amazonlinux /bin/bash Bonus While Amazon Linux is a secure, trusted, and lightweight container image, AWS also offers purpose built container image called Bottlerocket, which is a Linux-based open-source operating system. Bottlerocket includes only the essential software required to run containers, and ensures that the underlying software is always secure. Additionally, Bottlerocket is available at no cost as an Amazon Machine Image (AMI) for Amazon Elastic Compute Cloud (Amazon EC2) and can be used on Amazon EKS and Amazon ECS setups. Sign container images Container image signing can help verify that the trusted images you have selected and vetted are in use throughout your build pipelines and deployments. This process involves trusted parties cryptographically signing images so that they can be verified when used. This can be used to also sign and verify images throughout your organization. Container image signing is fairly lightweight. Because container images and runtimes have built-in integrity checks and all image content is immutable, signing solutions can simply sign image manifests. Signatures are stored alongside images in the registry, and at any point in time a consumer of the image can retrieve its signature and verify against a trusted publisher’s identity or public key. It is a good practice to sign and verify container images as part of overall security practices, and verifying public content establishes trust in content authenticity. With signed images, you can implement a solution that blocks images from running in your container environment unless they can be verified as trusted. This not only guarantees the authenticity of container images but also reduces the need for additional work to validate the container images in other ways prior to their use. For a full walkthrough of such a solution, see the recent launch of Container Image Signing with AWS Signer and Amazon EKS. Limit the number of layers It is a good practice to limit the number of layers in your container images. Having a large number of layers can increase the size and complexity of the image, which can make it more difficult to manage and maintain. For example, consider the following Dockerfile: FROM public.ecr.aws/docker/library/alpine:3.17.2 # Install all necessary dependencies in a single layer RUN apk add --no-cache \ curl \ nginx \ && rm -rf /var/cache/apk/* # Set nginx as the entrypoint ENTRYPOINT ["nginx"] In this example, we install all necessary dependencies in a single layer, and then remove the cache to reduce the number of layers in the final image. This results in a smaller and more efficient image that is easier to manage and maintain. Make use of multi-stage builds A multi-stage build is a technique that allows you to separate the build tools and dependencies from the final image content. This can be beneficial for several reasons: Reducing image size: By separating the build stage from the runtime stage, you can include only the necessary dependencies in the final image, rather than including all of the build tools and libraries. This can significantly reduce the size of your final image as and reduce the total number of image layers. Improved security: By including only the necessary dependencies in the final image, you can reduce the attack surface of the image. This is because there are fewer packages and libraries that could potentially have vulnerabilities. Here is an example of a multi-stage build in a Dockerfile: # Build stage FROM public.ecr.aws/bitnami/golang:1.18.10 as builder WORKDIR /app COPY . . RUN go build -o app . # Runtime stage FROM public.ecr.aws/amazonlinux/amazonlinux:2023 RUN yum install -y go WORKDIR /app COPY --from=builder/app ./ ENTRYPOINT ["./app"] In this example, we first use the golang:1.18.10 image as the build stage, in which we copy the source code and build the binary. Then, in the runtime stage, we use the amazonlinux:2023 container image, which is a minimal base image, and copy the built binary from build stage. This results in a smaller and more secure final image that only includes the necessary dependencies. Secure your secrets Secrets management is a technique for securely storing and managing sensitive information such as passwords and encryption keys and also externalizing environment specific application configuration. Secrets should not be stored in an image but instead stored and managed externally in service such as AWS Secrets Manager. For secrets that are required for your application during runtime, you can retrieve them from AWS Secrets Manager in real-time or use container orchestrator service such as Amazon ECS or Amazon EKS to mount secrets as volumes on the container such that the application can read from the mounted volume. Details on how secrets can be used on Amazon EKS can be found here and how secrets can be used on Amazon ECS can be found here. If secrets are required during build time, then you can inject ephemeral secrets using Docker’s secret mount-type. For example, the following Dockerfile uses a multi-stage build process where the first stage called builder_image_stage uses mount=type=secret to load the AWS credentials. The second stage then uses the build artifacts from first builder_image_stage. The resulting final image from second stage won’t contain any build tools or secrets from the builder_image_stage thereby not maintaining secrets on it. FROM public.ecr.aws/amazonlinux/amazonlinux:2023 AS builder_image_stage WORKDIR /tmp RUN yum install -y unzip && \ curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" && \ unzip /tmp/awscliv2.zip && \ /tmp/aws/install RUN --mount=type=secret,id=aws,target=/root/.aws/credentials \ aws s3 cp s3://... /app/... # cd /app # make FROM public.ecr.aws/amazonlinux/amazonlinux:2023 COPY --from=builder_image_stage /app/files_from_builder_image /app Reduce the attack surface Images, by default, are not secure and can potentially be vulnerable for attacks. Following approaches can help mitigate the attack surface. Build from scratch Most images are based on an existing base image such as Amazon Linux, ubuntu, alpine, etc. However, if you need to create a completely new base image with your own distribution, or if your application or service can be deployed as a single statically linked binary, you can use the special scratch image as a starting point. The scratch base image is empty and doesn’t contain any files. All of the official base images are actually built on top of scratch, and you can place any content on subsequent image layers. Using FROM scratch is basically a signal to the image build process that the layer built by the next command in the Dockerfile should be the first layer of the image. Scratch gives you the ability to completely control the contents of your image starting from the beginning. It is important to note that using scratch, you’ll be responsible for the entire toolchain and all content in the resulting container image. Also, container scanning solutions, such as Amazon ECR Enhanced Scanning, do not support vulnerability scanning of images without an OS packaging system in place. If your container images have many environmental dependencies or use interpreted languages or need vulnerability scanning, then using a minimal base image instead of scratch may be better. Here are a few examples of using scratch. The example below adds hello-world executable to the image as a first layer. FROM scratch ADD hello-world / CMD ["/hello-wold"] The second example copies the root filesystem to the root of the image as a first layer. The container uses this root filesystem to spin off processes from binaries and libraries in that directory. FROM scratch ADD root-filesystem.tar.gz / CMD ["bash"] Remove unwanted packages It is a good practice to remove any unwanted or unnecessary packages from your container image to reduce the attack surface and size of the image. For example, if your application does not require certain libraries or utilities, you should remove them from the image. Here is an example on how to remove package manager that may be unnecessary on a final image. FROM public.ecr.aws/ubuntu/ubuntu:20.04_stable # Remove package manager RUN apt-get -y --allow-remove-essential remove apt Use a Minimal Base Image Choosing a minimal base image, such as a Distroless image, can help to restrict what is included in your runtime container. Distroless images only include your application and its runtime dependencies that is necessary for the application to run. As such they don’t contain package managers or shells. This can improve the security and performance of your container by reducing the attack surface, as there are fewer packages and libraries that could potentially have vulnerabilities or add unnecessary overhead. Here is an example of using the Distroless base image for a Go application. This base image contains a minimal Linux, glibc-based system and is intended for use directly by mostly-statically compiled languages like Go, Rust or D. For more information, see the GitHub documentation on base distroless image. FROM gcr.io/distroless/base COPY app /app ENTRYPOINT ["/app"] Secure image configuration Images by default may not be secure and can allow privileged access. It is best to ensure that they are setup with least privileged access and remove configurations that are unnecessary for your application. One such approach is to run containers as a non-root user. Processes within Docker containers have root privileges by default to both the container and the underlying host. This opens up the container and host to security vulnerabilities that can be exploited. To prevent these vulnerabilities, it is a good practice to minimize the privileges granted to your container images, only giving the necessary permissions to perform required tasks. This helps to reduce the attack surface and potential for privilege escalation. On Dockerfile, you can use USER directive to specify a non-root user to run the container, or use the securityContext field in the Kubernetes pod specification to specify a non-root user and set group ownership and file permissions. Furthermore, on Kubernetes with Amazon EKS, you can also limit the default capabilities assigned to a POD as explained on EKS best practices Guides. For example, consider the following Dockerfile: FROM public.ecr.aws/amazonlinux/amazonlinux:2023 # 1) install package for adduser # 2) create new non-root user named myuser # 3) create app folder # 4) remove package for adduser RUN yum install -y shadow-utils && \ adduser myuser && \ mkdir /app && \ yum install -y remove shadow-utils COPY . /app # Set group ownership and file permissions RUN chown -R myuser:myuser /app # Run as non-root user USER myuser # Set entrypoint ENTRYPOINT ["/app/myapp"] In this example, we create a non-root user named myuser and set the group ownership and file permissions of the application files to this user. We then set the entry point to run as the myuser user, rather than as root. This helps to reduce the potential for privilege escalation and increase the security of the container. Tag Images When building container images, it is recommended to use tags to identify them. If the image is built without any tags, then Docker will assign latest as the default tag. For instance, when building an image, you may use the following command: docker build -t my-pricing-app . With this command, Docker automatically assigns the latest tag to the image, since no specific tag was provided. However, building an updated image using the same command assigns the latest tag to the new image. This can cause ambiguity and potential deployment of outdated or unverified versions. To avoid this, consider tagging the image descriptively as below: docker build -t my-pricing-app:<git-commit-hash>-1.0-prod . This command builds the my-pricing-app image tagged as <git-commit-hash>-1.0-prod. This allows specific version of the image to be deployed unlike latest tag. Additionally, you can also use the tag command to tag existing images. It is important to note that Docker tags are mutable by design, which allows you to build a new image with an existing tag. If you need to have immutable tags, then you can consider using Amazon Elastic Container Registry (Amazon ECR) to store your images. Amazon ECR supports immutable tags, which is a capability that prevents image tags from being overwritten. This enables users to rely on the descriptive tags of an image as a reliable mechanism to track and uniquely identify images and also trust that they have not been tampered with. More details can be found at Image tag mutability – Amazon ECR. Conclusion In this post, we showed you how to build better container images using best practices. As adoption of containers increase, it becomes important to ensure the container images are secure, lightweight, and are built from trusted sources. The options described in this post can act as a starting point to building such images. Additionally, this post also shows how users can use a secure and fully managed Amazon ECR to manage container images. View the full article

When it comes to container orchestration tools for managing and scaling microservices, two of the biggest tools in the market are Kubernetes and Amazon Elastic Container Service (ECS). Choosing the right tool can have a significant impact on your application’s scalability, management, and overall operational efficiency. In this blog post, we will thoroughly review each tool individually, discussing its advantages and disadvantages. By the end of the comparison, you will have a clear understanding of which container orchestration tool, Kubernetes or Amazon ECS, is the most suitable choice for your web application based on your company’s specific needs. So, let’s dive into the details and evaluate these two popular options. Amazon ECS vs. Kubernetes: Ultimate Comparison In the world of container orchestration, Kubernetes and Amazon Elastic Container Service (ECS) are two prominent tools. Kubernetes, developed by Google and hosted in the cloud, is a widely adopted container orchestration service that leverages Docker. It boasts a robust community and ecosystem. On the other hand, Amazon ECS is a container orchestration tool that excels in scalability. It dynamically creates additional containers to meet application demand. Both tools have their own set of strengths and weaknesses, making it crucial to thoroughly review them in order to make an informed decision that aligns with your business requirements. Amazon Elastic Container Service (ECS) and Kubernetes are two prominent container orchestration platforms that offer powerful capabilities for managing containerized applications. While both solutions serve the purpose of container orchestration, they have distinct differences in terms of architecture, management philosophy, scalability, and ecosystem integration. In this comprehensive comparison, we will delve into the key aspects of Amazon ECS and Kubernetes to help you make an informed decision about which platform is better suited for your specific needs. Architecture ECS follows a simpler architecture, with a control plane managed by AWS. It uses a task definition to define the containerized application’s specifications and runs tasks on EC2 instances or AWS Fargate, a serverless computing engine. www.amazon.com Kubernetes employs a more complex architecture with a master control plane and worker nodes. It uses various components like the API server, scheduler, and controller to manage containers, services, and resources across a cluster of nodes. www.kubernetes.io Management Experience Amazon ECS provides a fully managed experience, where AWS handles the underlying infrastructure and manages the control plane. This simplifies the setup and management process, making it easier for users to focus on deploying and scaling applications. Kubernetes offers a flexible and customizable experience but requires more configuration and management effort. Users have more control over the environment but need to handle tasks like cluster setup, scaling, and upgrades themselves. Scalability and Flexibility The scalability of container orchestration platforms is a critical factor to consider when choosing the right tool for your needs. Both Kubernetes and Amazon ECS have made significant strides in scaling their deployments to accommodate larger clusters. With the release of Kubernetes version 1.6, the platform introduced the ability to scale up to 5,000 node clusters. This means that Kubernetes can effectively handle the management and orchestration of a vast number of nodes within a single cluster. Additionally, if the need arises to scale beyond this limit, Kubernetes supports the use of multiple clusters, allowing for further scalability. Similarly, Amazon ECS has demonstrated its scalability by successfully scaling up to over a thousand container nodes without noticeable performance degradation. This showcases its ability to handle large-scale deployments and accommodate the growth of containerized applications. ECS provides robust scaling capabilities, allowing users to scale their tasks or services automatically based on predefined rules or application demand. It integrates seamlessly with other AWS services, such as Auto Scaling, ELB, and CloudWatch, to achieve dynamic scaling. Meanwhile, Kubernetes offers extensive scaling features, including horizontal pod autoscaling and cluster autoscaling. It allows users to define custom scaling rules and can scale workloads across multiple clusters or even cloud providers. Ecosystem and Community Amazon ECS benefits from the extensive AWS ecosystem, including various complementary services like AWS Fargate, Amazon ECR for container registry, and integration with AWS IAM, CloudWatch, and CloudFormation. However, the ECS community is relatively smaller compared to Kubernetes. On the other hand, Kubernetes has a vast and thriving community, with a rich ecosystem of third-party tools, plugins, and integrations. It supports multiple container runtimes, cloud providers, and operating systems, providing more flexibility and choice. Learning Curve and Adoption The Amazon ECS offers a simpler learning curve, making it easier for users to get started quickly, especially if they are already familiar with AWS services. It is well-suited for organizations heavily invested in the AWS ecosystem. Kubernetes has a steeper learning curve, requiring users to understand its concepts, APIs, and YAML-based configurations. However, Kubernetes has gained widespread adoption and is considered a de facto standard for container orchestration, making it a valuable skill in the industry. Advantages of Kubernetes over Amazon ECS Here are some pros and cons of Kubernetes over Amazon ECS have been listed below: Deployment Flexibility: Kubernetes can be deployed on-premises, in private clouds, and public clouds, providing greater flexibility and avoiding vendor lock-in. It can run on any x86 server or even on laptops, enabling organizations to choose the deployment environment that best suits their needs. In contrast, Amazon ECS is limited to running containers on the Amazon platform. Wide Variety of Storage Options: Kubernetes supports a wide range of storage options, including on-premises SANs and public cloud storage services. This flexibility allows organizations to utilize their existing storage infrastructure or leverage storage solutions from different providers. In contrast, Amazon ECS primarily relies on Amazon’s storage solutions, such as Amazon EBS, limiting the options for external storage. Extensive Experience from Google: Kubernetes is built on Google’s extensive experience in running Linux containers at scale. The platform inherits valuable insights and best practices from Google’s internal container management systems. This experience contributes to the robustness and reliability of Kubernetes, making it a trusted choice for organizations. Enterprise Offerings and Support: Kubernetes is backed by enterprise offerings from both Google (Google Kubernetes Engine – GKE) and RedHat (OpenShift). These offerings provide additional features, support, and services tailored for enterprise environments. They ensure that organizations have access to professional support and enterprise-grade capabilities when using Kubernetes. In comparison, Amazon ECS is validated and supported within the Amazon ecosystem and does not have as many options for enterprise-grade support outside of Amazon. Largest Community and Open Source: Kubernetes boasts the largest community among container orchestration tools, with over 50,000 commits and 1200 contributors. This vibrant community ensures a wealth of resources, including extensive documentation, tutorials, plugins, and third-party integrations. It also promotes rapid development and innovation within the platform. In contrast, while Amazon ECS has open-source components like Blox, the overall community and code contributions are smaller. Considering these advantages, Kubernetes offers greater deployment flexibility, a wider range of storage options, industry expertise from Google, extensive community support, and enterprise-grade offerings from multiple vendors. These factors make Kubernetes an attractive choice for organizations looking for a highly flexible and widely adopted container orchestration solution. Common features between ECS and Kubernetes The common features that exist between Amazon ECS and Kubernetes were listed below: Networking Both Kubernetes and Amazon ECS provide networking features such as load balancing and DNS. They enable applications to be accessed from the internet and distribute traffic among containers or instances. Overall, Kubernetes offers flexibility, multi-cloud support, a rich ecosystem, advanced scaling capabilities, and industry adoption, making it a powerful choice for container orchestration. Its ability to avoid vendor lock-in and provide granular control over workload scaling sets it apart from ECS and other container services, allowing organizations to leverage the most suitable platform for their evolving needs. Logging and Monitoring For Kubernetes, there are various external tools available for logging and monitoring, including Elasticsearch/Kibana (ELK), Heapster/Grafana/InfluxDB. These tools offer capabilities for collecting logs, analyzing performance metrics, and visualizing data. In the case of Amazon ECS, the partner ecosystem includes external tools such as Datadog and Sysdig Cloud, in addition to the built-in logging and monitoring services provided by AWS CloudWatch and CloudTrail. These tools offer similar functionalities for logging, monitoring, and analyzing containerized applications in the ECS environment. Autoscaling Both Kubernetes and Amazon ECS support native autoscaling. This means that the container orchestration platforms can automatically scale the number of running instances or containers based on predefined metrics or rules. Autoscaling helps maintain application performance and efficiently utilize resources by adjusting the container or instance count as demand fluctuates. Management Tools Kubernetes management actions can be performed using the kubectl command-line interface (CLI) and the Kubernetes Dashboard, a web-based user interface. These tools allow users to manage and control various aspects of their Kubernetes clusters and applications. In the case of Amazon ECS, management can be done through the AWS Management Console, which provides a graphical user interface (GUI) for managing ECS resources, configuring services, and monitoring containers. Additionally, the AWS Command Line Interface (CLI) offers a command-line tool for interacting with ECS and performing management tasks. Both Kubernetes and Amazon ECS offer networking capabilities, logging, and monitoring options, support for autoscaling, and management tools. However, the specific tools and services may differ, and users can choose based on their preferences and requirements. FAQs Why is Kubernetes superior to ECS? If you have complete and detailed control over whether your workload can scale using Kubernetes. When you need to transition to a more powerful platform, you may prevent vendor lock-in with ECS or any of the other container services by doing this. Is Kubernetes similar to Amazon ECS? Amazon ECS is comparable to EKS, except instead of using Kubernetes, it uses a proprietary control plane. The hosting infrastructure must be provisioned by the user, but ECS manages container orchestration. What distinguishes ECS and EKS most significantly? Elastic Kubernetes Service (AWS EKS) is a completely managed Kubernetes service, whereas Elastic Container Service (AWS ECS) is a fully managed container orchestration service. This is the main distinction between AWS EKS and AWS ECS. Whether Amazon ECS is scalable? AWS’s ECS is a fully-managed, highly scalable container orchestration solution. It makes running, stopping, and managing Docker containers on a cluster simple. For individuals who already use AWS and are looking for an easy way to run and grow containerized apps, the service is a popular option. Amazon Elastic Container Service is primarily used for? Amazon Elastic Container Service (ECS) is primarily used for container orchestration and management. It allows you to run and manage Docker containers in a highly scalable and reliable manner. Conclusion After closely examining the features and characteristics of Kubernetes and Amazon ECS, it is time to determine which container orchestration tool is the best fit for your needs. If you require multi-cloud capabilities and want the flexibility to deploy your applications across various cloud providers, Kubernetes emerges as the clear choice. Its extensive community support, rich ecosystem, and ability to work with multiple container runtimes make it an ideal option for organizations seeking a multi-cloud strategy. On the other hand, if your primary focus is on reducing IT labor, hosting costs, and management complexity, Amazon ECS is the recommended choice. Its fully managed nature and seamless integration with other AWS services simplify the deployment and scaling processes, allowing you to focus more on your applications rather than infrastructure management. Ultimately, the decision between Kubernetes and Amazon ECS depends on your specific requirements and priorities. To learn more about Amazon ECS and Kubernetes, try our hands-on labs and sandboxes. If you have any questions about this blog post, please feel free to comment us! View the full article

Last August, we announced 6 MB-size Ubuntu base images designed for self-contained .NET applications — we called them “chiselled Ubuntu”. How did we make our Ubuntu base images 15 times smaller? And how can you create your own chiselled Ubuntu images? In this blog, I explain the idea behind Distroless container images, which inspired us to create chiselled Ubuntu images — adding the “distro” back to distro-less! In a follow-up blog, I will then provide a step-by-step example of how you can create your own chiselled Ubuntu base container images, built for your specific needs. At-scale comparison of popular base images’ sizes (compressed and uncompressed) Introduction to Distroless container images Thanks to the widespread use of container images, developers now have an easy way to package an application and its dependencies into a self-contained unit compatible with any platform supporting the “OCI” standard (for example, Docker, Kubernetes or one of The 17 Ways to Run Containers on AWS). Container images make it easy to package and run applications in a consistent environment without worrying about differences in the host operating system or runtime environment. Distroless container images are ultra-small images that only include an application and its runtime dependencies without additional libraries or utilities from a Linux distribution. This makes them smaller and more secure than traditional container images, which often include many libraries and utilities that are not needed by the application. In particular, traditional images often have a package manager and shell that give them their “look and feel”. In opposition, we could call them “distro-full”. Minimal and mighty: the benefits of Distroless container images Smaller container images have a de facto smaller attack surface, decreasing the likelihood of including unpatched security vulnerabilities and removing opportunities for attackers to exploit. But this probabilistic approach needs to consider how well-maintained the remaining content is. A large image with no CVEs and regular security updates is safer than an ultra-small unstable unmaintained one. The ultimate security of a containerised application depends on various factors, including how it is designed and deployed and how it is maintained and updated over time. Using a well-maintained and supported Linux distribution like Ubuntu can help improve the security of containerised applications. Additionally, smaller container images can save time and resources, especially in environments with limited storage capacity or where many container images are being used. The best of both worlds: introducing Chiselled Ubuntu container images Chiselled Ubuntu is a variation of Distroless container images built using the packages from the Ubuntu distribution. Chiselled Ubuntu images are carefully crafted to only fit the minimum required dependencies. They are constructed using a developer-friendly package manager called “Chisel”, which is only used at build time and not shipped in the final image. This makes them smaller and more secure than traditional Ubuntu container images, which often include many additional libraries and utilities. Chiselled Ubuntu images inherit the advantages of the Ubuntu distribution: regularly updated and supported, offering a reliable and secure platform for creating and operating applications. On the other hand, they suppress the downsides of using a “distro-full” image when shipping to production. “Breaking the Chisel” – how Chisel works Chisel uses an open database of package slices, which supersedes the Debian packages database with specific file subsets and edited maintainer scripts for creating ultra-small runtime file systems. Chisel is a sort of “from-scratch package manager” that creates partial filesystems that just work for the intended use cases. The information contained in a Package slice is what image developers used to define manually at the image definition level when crafting Distroless-type images. With Chisel, community developers can now easily reuse this knowledge – effortlessly. Illustration of Package slices, reusing upstream Ubuntu packages information Chiselled Ubuntu container images are a new development that offers many benefits, including a consistent and compatible developer experience. They are slices of the same libraries and utilities in the regular Ubuntu distribution, making it easy to go from using Ubuntu in development to using chiselled Ubuntu in production. As a result, multi-stage builds work seamlessly with chiselled Ubuntu images. Next steps: creating your own chiselled Ubuntu base container images In conclusion, chiselled Ubuntu container images combine the benefits of Distroless containers with those of Ubuntu to create smaller, more secure containers that are easier to use. In this blog, I have explained the idea behind Distroless containers and introduced the concept of chiselled Ubuntu images. In the next blog, I will provide a step-by-step guide for creating chiselled Ubuntu base container images built for your specific needs. Ready? Keep reading! Chisel in GitHub:https://github.com/canonical/chisel Open Source Summit Europe 2022 presentation on Chiselled Ubuntu Chiselled Ubuntu for .NET announcement Microsoft .NET developers’ 2022 conf x Chiselled Ubuntu keynote That’s what chiselled Ubuntu containers could look like… well, if you ask the DALL-E2 AI. View the full article

For many companies today, containers and microservices are both becoming a normal part of the industry landscape. According to a global survey put out by Statista in 2021, 19% of enterprise organizations today say they are already utilizing containers to achieve their business goals, while 92% of respondents claim microservices to be a success factor. […] The post How Can Containers Help You Use Microservices in DevOps? appeared first on DevOps.com. View the full article

Overview Data transfer costs can play a significant role in determining the overall design of a system. Amazon Elastic Container Registry (Amazon ECR), Amazon Elastic Container Service (Amazon ECS), and Amazon Elastic Kubernetes Service (Amazon EKS) can incur data transfer charges depending on a variety of factors. It can be difficult to visualize what that means relative to an Amazon ECS or Amazon EKS deployment. This blog illustrates common deployment patterns for AWS container services and explains the resulting data transfer charges that might be incurred. Amazon ECR There are two types of Amazon ECR registries—public and private—and each one has different data transfer charges. Amazon ECR public registry Amazon ECR Public is a managed AWS container image registry service that is secure, scalable, and reliable. Amazon ECR supports public image repositories with resource-based permissions using AWS Identity and Access Management (IAM) so that specific users can access your public repositories to push images. Developers can use their preferred command line interface (CLI) to push and manage Docker images, Open Container Initiative (OCI) images, and OCI-compatible artifacts. Images are publicly available to pull, either anonymously or through an Amazon ECR Public authentication token. All data transferred into Amazon ECR Public incurs no charge from Amazon ECR. Data transferred out is subject to charges when more than 5 TB per month are transferred out to non AWS destinations and you have authenticated to Amazon ECR with an AWS account. Up to 500 GB per month can be anonymously transferred out to non AWS destinations to clients that have not authenticated. After that limit is reached, no further anonymous data transfers are allowed. Figure 1. Amazon ECR public registry Amazon ECR private registry An Amazon ECR private registry hosts container images in a highly available and scalable architecture. You can use an Amazon ECR private registry to manage private image repositories consisting of Docker and OCI images and artifacts. Data transferred into the Amazon ECR private registry incurs no charge from Amazon ECR. Data transferred between Amazon ECR and other services within the same Region is free. Data transferred between Amazon ECR and other services in different Regions is charged at internet data transfer rates on both sides of the transfer. Note that this is aggregated with other outbound data transfers across multiple services, and rate tiers apply based on the amount of data transferred. Figure 2. Amazon ECR private registry Amazon ECR offers built-in functionality to replicate container images to different locations. This could be useful for disaster recovery purposes, a promote-to-production pipeline, and image pull time and data transfer cost reductions when running containers in different Regions. This data transfer is charged at the cross-Region data transfer rates described on the Amazon Elastic Compute Cloud (Amazon EC2) On-Demand Pricing page. Refer to the Amazon ECR Pricing page and Amazon EC2 On-Demand Pricing page for more information. Data transfers for Amazon ECS Three common deployment models for Amazon ECS are Amazon ECS Anywhere, clusters with external network access, and clusters without external network access. Amazon ECS Anywhere Amazon ECS Anywhere is a feature of Amazon ECS that lets you easily run and manage container-based applications on premises, including on your own virtual machines (VMs) and bare-metal servers. With Amazon ECS Anywhere, you do not need to install or operate local container orchestration software, thus reducing operational overhead. Amazon ECS Anywhere offers a completely managed solution that lets you standardize container management across all of your environments. Data transfer fees are accrued based on how the customer-managed infrastructure connects to the Amazon ECS Anywhere control plane. If connecting through the internet (Figure 3), there is no charge for data transfers when communication occurs over the open internet between the Amazon ECS Anywhere control plane and Amazon ECS agent. Figure 3. Amazon ECS Anywhere communication over the internet If connecting through AWS Site-to-Site VPN or AWS Direct Connect (Figure 4), standard data transfer fees (data transfer out fees) apply to Site-to-Site VPN or Direct Connect when communication occurs between the Amazon ECS Anywhere control plane and Amazon ECS agent through Site-to-Site VPN or the Direct Connect link. Figure 4. Amazon ECS Anywhere with AWS Direct Connect Refer to the Amazon ECS Anywhere Pricing page, AWS Site-to-Site VPN Pricing page, and AWS Direct Connect Pricing page for more details. Amazon ECS clusters with external access Compute capacity for container instances in Amazon ECS can be deployed within virtual private clouds (VPCs) that allow access to the Amazon ECS service endpoint using the internet. For example, the compute capacity for container instances can be deployed in public subnets (with an internet gateway) or private subnets (with a NAT gateway—shown in Figure 5), or it can route to the internet through another VPC, such as Amazon Virtual Private Cloud (Amazon VPC), using AWS Transit Gateway. Both Amazon EC2 and AWS Fargate can be used for the compute capacity in this type of deployment, and there is no difference in data transfer costs based on which service is chosen. Figure 5. Amazon ECS deployment with internet access The following data transfers are not charged for in the sample deployment: Data transferred in from the Amazon ECS control plane (responses to API calls from the data plane) and Amazon ECR (image pulls) Communication between tasks and the Application Load Balancer (assuming targets are available in each Availability Zone and avoid cross-zone load balancing) Communication between tasks and the database instance in the same Availability Zone In this deployment, data transfer charges accrue for the following: Data transferred out through the NAT gateway, including polling traffic from the Amazon ECS agent to the Amazon ECS control plane and outbound data to Amazon ECR Cross-Availability Zone traffic to the database It is important to note that although the NAT gateway does not charge for data transferred in, there is still a data processing charge per gigabyte on data that flows through the NAT gateway, regardless of direction. The data transfer out charges are in addition to this charge. The NAT gateway pricing can be found on the Amazon VPC Pricing page. Amazon ECS clusters with no external access Another common pattern to deploy Amazon ECS workloads is to restrict all external network access (Figure 6). Because container instances in Amazon ECS clusters need external network access to communicate with the Amazon ECS service endpoint, AWS PrivateLink must be used to communicate with the service endpoints. Again, both Amazon EC2 and Fargate can be used for the compute capacity in this type of deployment. However, there is a difference in data transfer costs based on which service is chosen. The following data transfers are not charged for in the sample deployment: Communication between tasks and the Application Load Balancer Communication between tasks and the database instance in the same Availability Zone In this deployment, data transfer charges accrue for cross-Availability Zone traffic to the database. The diagram depicts the Amazon ECS and Amazon ECR PrivateLink VPC interface endpoints as single objects. However, there are actually multiple endpoints required for each. For a description of endpoint requirements, consult this AWS Compute blog post or the Amazon ECS and Amazon ECR documentation. Figure 6. Amazon ECS deployment in private network Although there is no data transfer fee, PrivateLink imposes both a per-hour service charge and a per-gigabyte data processing charge for data processed through each VPC endpoint, billed per Availability Zone. More details can be found on the AWS PrivateLink Pricing page. Using AWS Fargate in private Amazon ECS clusters If Fargate provides the compute capacity for the Amazon ECS cluster, the PrivateLink endpoints for Amazon ECS are not required. This gets rid of the hourly and data processing service charges for communication to the Amazon ECS service endpoint. Note that the PrivateLink VPC endpoints for Amazon ECR are still required to pull images from Amazon ECR. Data transfer for Amazon EKS Similar to Amazon ECS, Amazon EKS data transfer charges follow the guidelines described on the Amazon EC2 Pricing page. Figure 7 represents a sample Amazon EKS workload with two pods deployed to different Amazon EKS worker nodes in different Availability Zones. The following data transfers are not charged in this example: Traffic in and out of the control plane (not shown on the diagram) Image pulls from Amazon ECR (not shown on the diagram) Communication between pods and the Application Load Balancer Communication between pods and the database instance in the same Availability Zone The following data transfers have accrued charges in this example: Data transfer between the Kubernetes pod and database in a different Availability Zone Data out (egress) from the Application Load Balancer Communication between pods in different Availability Zones Figure 7. Sample application of Amazon EKS deployment There are several other configuration options and deployment strategies to consider in an Amazon EKS deployment relative to data transfer costs, such as cluster access (public or private), pod-to-pod communication, and communication between the pods and the load balancer. Public Amazon EKS clusters Public Amazon EKS clusters (Figure 8) have the public endpoint access turned on and the private endpoint turned off. Communication between the control plane and worker nodes exits the VPC based on the VPC’s routing. For worker nodes in private subnets, communication traverses a NAT gateway and exits through an internet gateway. There is no data transfer charge associated with this. However, there is a per-gigabyte NAT gateway data processing fee. In addition, worker nodes that are not in the same Availability Zone as the NAT gateway incur a per-gigabyte data transfer charge for cross-Availability Zone traffic. For worker nodes in public subnets, communication exits the internet gateway and is not charged. Figure 8. Public Amazon EKS cluster Private Amazon EKS clusters In a cluster with private Amazon EKS endpoints (Figure 9), worker nodes communicate with private endpoints. The Kubernetes API server endpoint URL resolves to elastic network interfaces within the (customer) VPC. Worker nodes inside the VPC communicate with these network interfaces. In this deployment model, there is a chance that a worker node communicates with a network interface in a different Availability Zone. This communication is subject to a cross-Availability Zone data transfer charge. Figure 9. Private Amazon EKS cluster Pod-to-pod communication Kubernetes applications often use communication between containers and pods (Figure 10). Containers within the same pod are guaranteed to be on the same worker node and communicate over the loopback device, resulting in no data transfer charges. Data transfer charges between pods depend on the pod placement: There is no data transfer charge for pods deployed on the same node or within the same Availability Zone Pods that communicate and are placed in different Availability Zones incur a data transfer charge Figure 10. Pod-to-pod communication Load balancer-to-pod communication Amazon EKS workloads often include a load balancer to evenly distribute the traffic across pods. Pods are deployed alongside Kubernetes Service and Ingress objects. The add-on AWS Load Balancer Controller monitors these objects and automatically provisions the AWS load balancer resource. The path that traffic takes and resulting data transfer charges depend on how the Service and Ingress objects are configured. There are two common methods of configuration. The first method involves having a target group that consists of all worker nodes within the cluster (Figure 11). This grouping includes Service: LoadBalancer, Service: NodePort, and Ingress TargetType: instance. Here, an ephemeral port (NodePort) is opened on each node in the cluster, and traffic is distributed evenly across all nodes. If the destination pod is on the node, no additional data transfer occurs. If the destination pod is scheduled on a different node, data transfer charges might accrue if the target pod is in a different Availability Zone. Figure 11. Load balancer-to-pod communication using TargetType: instance The second method involves a target group consisting of the pod IP addresses (Figure 12). In this method, the load balancer targets are the IP addresses of the pods. Communication bypasses the kube-proxy and targets the pod directly, keeping traffic in the same Availability Zone and avoiding data transfer charges. Figure 12. Load balancer-to-pod communication using TargetType: IP Tips The following are tips to avoid excess data transfer and data processing charges in your container workloads: Additional components in the network path, such as NAT gateways, PrivateLink, or Transit Gateway, might incur additional data transfer or data processing charges. Review potential data transfer charges at both the source and target of your communication channel. Remember that “data transfer in” to a destination is also “data transfer out” from a source. Limit cross-Region data transfer where possible. Use the Amazon ECR built-in cross-Region replication features to limit what is replicated. Use cross-Region data replication to replicate images in Amazon ECR into additional Regions and then pull images from the local Region. Try to limit container images to only the essentials required to run your workload. Images with extraneous binaries cost more to store and transfer, increase startup time, and increase the attack surface area. Determine the most efficient network path for your traffic. For example, do your requirements indicate a need for a private cluster with no external connectivity? As more networking components are added, data transfer costs increase. Consider consolidating PrivateLink endpoints in a central VPC connected by Transit Gateway, described in this AWS PrivateLink whitepaper. In an Amazon ECS deployment with no external network connectivity, consider using Fargate to host your containers. This gets rid of the need for the PrivateLink endpoint for Amazon ECS. When using a load balancer in your Amazon EKS workload, try to avoid NodePort services and target the pods directly using the IP-based TargetType for target groups. Conclusion In order to determine the most cost-efficient architecture for your container-based workloads, it’s important to understand how data transfer charges are calculated. Design decisions made related to compute capacity deployment, access to public AWS services, and general network architecture have an impact on data transfer charges. Interested in learning more? Check out the Overview of Data Transfer Costs for Common Architectures blog post for an explanation of data transfer charges for common network architectures, and be sure to visit the AWS Containers Blog for more great container-related content! View the full article

This blog focuses primarily on helping customers understand software supply chain security in the context of integrity and provenance—specifically, how cryptographic signatures can be used to simplify the process of ensuring the integrity of container images as they move through your software supply chain. We will also discuss how signing can help organizations validate their container images are coming from a trusted publisher, and how signing can be integrated with code scanning and approval workflows to facilitate a secure software supply chain. To be successful, signing and verification should be easily implemented and integrated with DevOps processes, ideally not placing undue burden on development teams to manage cryptographic keys and certificates. While this blog primarily covers signing container image manifests and related artifacts, cryptographic signatures can also be used to sign/verify documents, authentication tokens, software packages, and more. Today, building containers involves creating an image and putting it in a registry such as Amazon Elastic Container Registry Public (ECR Public), or Amazon ECR private registry; developers can then deploy containers from these repositories. Developers use code pipelines to build and deploy their container images. Building integrity verification for open source container images (as well as images built locally) into your CI/CD pipeline can reduce the risk of software supply chain attacks and provide continuous confidence to businesses using these container images across multiple business units. Put simply, we will examine the questions: What are cryptographic signatures, and how can they be used in a container build pipeline? How can organizations use signing to ensure that their container images are approved for use and have been verified as meeting their security standards? How can developers use signing to verify the container images they create haven’t been tampered with after they’re vetted and approved for use? View the full article

Manage your containers easily with table view and bulk remove ... https://www.docker.com/blog/new-extensions-and-container-interface-enhancements-in-docker-desktop-4-9/