Sysdig is the secure DevOps company, and we’re at the forefront of the container and Kubernetes revolution

Sysdig

sysdig

Sysdig is a universal system visibility tool with support for containers. What makes Sysdig special, is that it hooks itself into the machine's kernel and segregates the information on a per-container basis. For the scope of this tutorial, we will focus on the open-source version of Sysdig. In the next sections, you will: Install Sysdig Spin up a Wordpress installation using docker-compose Use Sysdig to collect events and analyze them at a later time Use Sysdig to analyze data in real-time Prerequisites Docker is installed on your system. For details about installing Docker, refer to the page. Install Docker Docker Compose is installed on your system. Refer to the page for instructions about how to install Docker Compose. Install Docker Compose The kernel headers are installed on the host system. Install Sysdig Follow these steps to install Sysdig inside a Docker container: 1. In a terminal window, execute the following command to pull the Sysdig Docker image: docker pull sysdig/sysdig Using default tag: latest
latest: Pulling from sysdig/sysdig
2967486b0658: Pull complete
78101b780c72: Pull complete
7e78b657334d: Pull complete
650327159ca8: Pull complete
47ebf73ab754: Pull complete
bf51ac76a6d9: Pull complete
0cd11104dbf6: Pull complete
e6dcf17d00d8: Pull complete
230d60083576: Pull complete
fd5ea9faf384: Pull complete
6de86c8ed6e9: Pull complete
8d1825f8be4b: Pull complete
Digest: sha256:bbfe6953fd2b3221a8974eb13024dd33c7e78aebef8fee3d7a0d9ecdeed84ce0
Status: Downloaded newer image sysdig/sysdig:latest for 2. Run Sysdig in a container by entering: docker run -i -t --name sysdig --privileged -v /var/run/docker.sock:/host/var/run/docker.sock -v /dev:/host/dev -v /proc:/host/proc:ro -v /boot:/host/boot:ro -v /lib/modules:/host/lib/modules:ro -v /usr:/host/usr:ro sysdig/sysdig * Setting up /usr/src links from host
* Unloading sysdig-probe, present
* Running dkms install sysdig
Error! Your kernel headers kernel 3.10.0-957.12.2.el7.x86_64 cannot be found at
/lib/modules/3.10.0-957.12.2.el7.x86_64/build or /lib/modules/3.10.0-957.12.2.el7.x86_64/ .
* Running dkms build failed, couldn if for echo for source 't find /var/lib/dkms/sysdig/0.26.4/build/make.log
* Trying to load a system sysdig-probe, if present
* Trying to find precompiled sysdig-probe for 3.10.0-957.12.2.el7.x86_64
Found kernel config at /host/boot/config-3.10.0-957.12.2.el7.x86_64
* Trying to download precompiled module from https://s3.amazonaws.com/download.draios.com/stable/sysdig-probe-binaries/sysdig-probe-0.26.4-x86_64-3.10.0-957.12.2.el7.x86_64-82e2ae1fb159132636f7b50a762f20ef.ko
Download succeeded, loading module
root@7b14a23f22eb:/# A few things to note about the above command: The flag keeps STDIN open. -i The parameter provides Also it sets SELinux to allow the processes running inside of the container the as a process running on the host. --privileged access to all devices on the host. same access to the host The flag specifies the list of files ( ) that Sysdig can access. -v on the host Spin Up a Wordpress Installation In this section, you will install Wordpress using the command. docker-compose 1. In a , move into your projects directory and type the following commands: new terminal window mkdir wordpress-sysdig && wordpress-sysdig cd 2. Create a file called with the following content: docker-compose version: services:
   db:
     image: mysql:5.7
     volumes:
       - db_data:/var/lib/mysql
     restart: always
     environment:
       MYSQL_ROOT_PASSWORD: somewordpress
       MYSQL_DATABASE: wordpress
       MYSQL_USER: wordpress
       MYSQL_PASSWORD: wordpress

   wordpress:
     depends_on:
       - db
     image: wordpress:latest
     ports:
       - restart: always
     environment:
       WORDPRESS_DB_HOST: db:3306
       WORDPRESS_DB_USER: wordpress
       WORDPRESS_DB_PASSWORD: wordpress
       WORDPRESS_DB_NAME: wordpress
volumes:
    db_data: {} '3.3' "8000:80" 3. Run the command in detached mode with: docker-compose up docker-compose up -d Creating network with the default driver
Creating volume with default driver
Pulling wordpress (wordpress:latest)...
latest: Pulling from library/wordpress
8ec398bc0356: Pull complete
85cf4fc86478: Pull complete
970dadf4ccb6: Pull complete
8c04561117a4: Pull complete
d6b7434b63a2: Pull complete
83d8859e9744: Pull complete
9c3d824d0ad5: Pull complete
9e316fd5b3b3: Pull complete
578b40496c37: Pull complete
814ae7711d3c: Pull complete
4896fed78b6b: Pull complete
e74d71e9611d: Pull complete
46017765526c: Pull complete
280386098458: Pull complete
f32eb0d8c540: Pull complete
5c47b9ea747a: Pull complete
ecda5b7aad12: Pull complete
84256a6b6b44: Pull complete
35d4f385efb7: Pull complete
bf697c2ae701: Pull complete
d054b015f084: Pull complete
Digest: sha256:73e8d8adf491c7a358ff94c74c8ebe35cb5f8857e249eb8ce6062b8576a01465
Status: Downloaded newer image wordpress:latest
Creating wordpress-sysdig_db_1 ... Creating wordpress-sysdig_wordpress_1 ... "wordpress-sysdig_default" "wordpress-sysdig_db_data" for done done 4. You can verify the status of your containers with: docker ps If all is going well, you should see something similar to the following output: CONTAINER ID        IMAGE               COMMAND                  CREATED              STATUS              PORTS                  NAMES
f390eec29f52        wordpress:latest About a minute ago   Up About a minute   0.0.0.0:8000->80/tcp   wordpress-sysdig_wordpress_1
a844840626d8        mysql:5.7 About a minute ago   Up About a minute   3306/tcp, 33060/tcp    wordpress-sysdig_db_1
7b14a23f22eb        sysdig/sysdig 13 minutes ago       Up 13 minutes                              sysdig "docker-entrypoint.s…" "docker-entrypoint.s…" "/docker-entrypoint.…" 5. Now Wordpress is up and running. Point your browser to to start the installation wizard: http://localhost:8000 6. Once the installation wizard is finished, let us go ahead and create a sample post: Collecting Data to a File In this section, we'll show how you can use Sysdig to collect events and analyze them at a later time. 1. To dump all captured events to a file, move to the Sysdig container, and enter the following command: sysdig -w monitoring-wordpress.scap 2. In a new terminal window, use to make 10000 requests with a maximum of 100 requests running concurrently: ab ab -n 1000 -c 100 http://localhost:8000/?p=7 This is ApacheBench, Version 2.3 < : 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests $Revision Note that the above output was truncated for brevity. 3. Move back to tour Sysdig container and stop capturing data by entering "CTRL+C". Analyzing data Now, if you look at the size of the file, you'll notice that Sysdig captured no less than 80M of data: monitoring-wordpress.scap ls -lh monitoring-wordpress.scap -rw-r--r--. 1 root root 80M Jan  7 16:28 monitoring-wordpress.scap To find your way through this mountain of data, you'll use something called a . chisel A chisel is basically a Lua script that analyzes the event stream and performs useful actions. You can run the following command to display the list of chisels: sysdig -cl Category: Application
---------------------
httplog         HTTP requests httptop         Top HTTP requests
memcachelog     memcached requests Category: CPU Usage
-------------------
spectrogram     Visualize OS latency real time.
subsecoffset    Visualize subsecond offset execution time.
topcontainers_cpu
                Top containers by CPU usage
topprocs_cpu    Top processes by CPU usage

Category: Errors
----------------
topcontainers_error
                Top containers by number of errors
topfiles_errors Top files by number of errors
topprocs_errors top processes by number of errors log log in Note that the above output was truncated for brevity. To retrieve detailed information about a chisel, run the command followed by the flag and the name of the chisel, as in the following example: sysdig -i sysdig -i httptop Category: Application
---------------------
httptop         Top HTTP requests

Show top HTTP requests by: ncalls, time or bytes
Args:
[string] by - Show top HTTP transactions by: ncalls, time or by
                tes, default is ncalls Continuing our example, here's how you can use the chisel to display the top HTTP requests: httptop sysdig -r monitoring-wordpress.scap -c httptop ncalls              method              url
--------------------------------------------------------------------------------
2001                GET                 localhost:8000/?p=7
14                  OPTIONS             *
2                   GET                 localhost:8000/favicon.ico
1                   GET                 /wp-content/themes/twentytwenty/assets/fonts/inter/Inter-upright-var.woff2
1                   GET                 localhost/v1.24/containers/6bd8418eb03f/json
1                   GET                 localhost/v1.24/containers/06def7875617/json
1                   GET                 /v1.24/images/1b1624b63467ec61fab209b6be6e79707ae786df86607b9474b246acd31600
1                   GET                 /v1.24/images/db39680b63ac47a1d989da7b742f7b382af34d85a68214f8977bad59c05901
1                   GET                 localhost:8000/ You can see the same information in a format with the flag: container-friendly -pcontainer sysdig -r monitoring-wordpress.scap -c httptop -pcontainer ncalls              container           method              url
--------------------------------------------------------------------------------
1000                wordpress-sysdig_wo GET                 localhost:8000/?p=7
1000                host                GET                 localhost:8000/?p=7
43                  wordpress-sysdig_wo OPTIONS             *
1                   sysdig              GET                 /v1.24/images/1b1624b63467ec61fab209b6be6e79707ae786df86607b9474b246acd31600
1                   sysdig              GET                 localhost/v1.24/containers/06def7875617/json
1                   sysdig              GET                 localhost/v1.24/containers/cd06093b141b/json
1                   sysdig              GET                 /v1.24/images/00e230fe24da9067f9b6e65cfbe9935a5affac1ae8e44edb6a5b0ccc26374d
1                   sysdig              GET                 /v1.24/images/db39680b63ac47a1d989da7b742f7b382af34d85a68214f8977bad59c05901 Digging Deeper Sysdig captures content-rich information that lets you get detailed insights into the inner-workings of your containers. Let's suppose you're running a few containers and want to know which process consumes the most CPU. 1. List the containers that were active during the period in which you captured events: sysdig -r monitoring-wordpress.scap -c lscontainers 2. You can identify the container that consumed the most CPU with: sysdig -r monitoring-wordpress.scap -c topcontainers_cpu CPU%                container.name
--------------------------------------------------------------------------------
5.37%               wordpress-sysdig_wordpress_1
1.35%               wordpress-sysdig_db_1
0.84%               host
0.51%               sysdig 3. You can dig even deeper and identify the most CPU intensive process with the chisel: topprocs_cpu sysdig -r monitoring-wordpress.scap -c topprocs_cpu container.name contains wordpress_1 CPU%                Process             PID
--------------------------------------------------------------------------------
0.12%               apache2             8383
0.11%               apache2             9413
0.11%               apache2             9300
0.11%               apache2             9242
0.11%               apache2             8897
0.11%               apache2             8422
0.10%               apache2             9372
0.10%               apache2             9241
0.10%               apache2             8424
0.09%               apache2             9429 If you want to see more details,  the chisel provides a more verbose alternative: ps sysdig -r monitoring-wordpress.scap -c ps container.name=wordpress-sysdig_wordpress_1 TID     PID     USER        VIRT       RES        FDLIMIT   CMD
5896    5896    root        232.82M    22.32M     429496729 apache2
8383    8383    www-data    307.44M    25.46M     429496729 apache2
8422    8422    www-data    235.44M    22.90M     429496729 apache2
8424    8424    www-data    307.44M    25.46M     429496729 apache2
8897    8897    www-data    235.44M    22.89M     429496729 apache2
9154    9154    www-data    235.44M    22.91M     429496729 apache2
9241    9241    www-data    307.44M    25.66M     429496729 apache2
9242    9242    www-data    307.44M    25.67M     429496729 apache2
9300    9300    www-data    235.44M    22.89M     429496729 apache2
9372    9372    www-data    235.44M    22.89M     429496729 apache2
9413    9413    www-data    233.44M    20.77M     429496729 apache2 Tips Useful If you run Sysdig to capture events as in the above example ( ), the event file will grow continuously until it consumes all the available space. There are a few methods that can help prevent this from happening: sysdig -w monitoring-wordpress.scap Specify the number of events Sysdig should capture by passing it the flag. Once Sysdig captures the specified number of events, it'll automatically exit: -n sysdig -n 5000 -w monitoring-wordpress.scap Use the flag to configure Sysdig so that it breaks the capture into smaller files of a specified size. The following example continuously saves events to files < 10MB: -C sysdig -C 10 -w monitoring-wordpress.scap This will create a bunch of files no larger than 10 MB: ls -lh monitoring-wordpress* -rw-r--r--. 1 root root 9.6M Jan  7 17:13 monitoring-wordpress.scap0
-rw-r--r--. 1 root root 9.6M Jan  7 17:14 monitoring-wordpress.scap1
-rw-r--r--. 1 root root 9.6M Jan  7 17:14 monitoring-wordpress.scap2
-rw-r--r--. 1 root root 9.6M Jan  7 17:14 monitoring-wordpress.scap3
-rw-r--r--. 1 root root 9.6M Jan  7 17:14 monitoring-wordpress.scap4
-rw-r--r--. 1 root root 9.6M Jan  7 17:14 monitoring-wordpress.scap5
-rw-r--r--. 1 root root 9.6M Jan  7 17:14 monitoring-wordpress.scap6
-rw-r--r--. 1 root root 9.6M Jan  7 17:14 monitoring-wordpress.scap7
-rw-r--r--. 1 root root 6.4M Jan  7 17:14 monitoring-wordpress.scap8 Specify the maximum number of files Sysdig should keep with the flag. For example, you can combine the and flags like so: -W -C -W sysdig -C 10 -W 4 -w monitoring-wordpress.scap The above command will only keep the last four capture files: ls -lh monitoring-wordpress* -rw-r--r--. 1 root root 7.2M Jan  7 17:21 monitoring-wordpress.scap0
-rw-r--r--. 1 root root 9.6M Jan  7 17:21 monitoring-wordpress.scap1
-rw-r--r--. 1 root root 9.6M Jan  7 17:21 monitoring-wordpress.scap2
-rw-r--r--. 1 root root 9.6M Jan  7 17:21 monitoring-wordpress.scap3
root@cd06093b141b:/ # sysdig -C 10 -W 4 -w monitoring-wordpress.scap Real-Time Monitoring With Sysdig, you can also analyze data real-time. At first glance, this can seem like a daunting task because, by default, all events are continuously printed out to the console. Fortunately, chisels are here to help. Let's take an example. Analyze Processes on a Per Container Basis 1. Run the following command to list your containers: docker ps CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                  NAMES
5b253e74e8e7        sysdig/sysdig 9 minutes ago       Up 9 minutes                               sysdig
06def7875617        wordpress:latest 3 hours ago         Up 3 hours          0.0.0.0:8000->80/tcp   wordpress-sysdig_wordpress_1
6bd8418eb03f        mysql:5.7 3 hours ago         Up 3 hours          3306/tcp, 33060/tcp    wordpress-sysdig_db_1 "/docker-entrypoint.…" "docker-entrypoint.s…" "docker-entrypoint.s…" 2. You can analyze the processes running in the WordPress container with: sysdig -pc -c topprocs_cpu container.name=wordpress-sysdig_wordpress_1 3. Similarly, you can analyze the processes running in the MySQL container: sysdig -pc -c topprocs_cpu container.name=wordpress-sysdig_db_1 Note that, not much different from this example, Sysdig can monitor network traffic, disk usage, and so on. In this tutorial, you have gone over the fundamentals of using Sysdig to get a clear understanding of the activity generated by your containers. The examples in this blog post helped you get started and, in future tutorials, we'll show you how to use and . Csysdig Sysdig Inspect

Sysdig: What It Is and How to Use It

Breaches and cyber attacks dominate headlines today. Hardly a week goes by without news of another massive data leak or ransomware attack bringing a company to its knees. In fact, studies show that the of organizations have experienced cyberattacks. As threats proliferate, organizations invest heavily in security tools and staff. large majority The average enterprise uses a ridiculous and technologies. More tools mean more alerts and more alerts lead to alert fatigue. Unsurprisingly, a found that too many tools decrease effectiveness, hindering cybersecurity efforts. Exhausted security teams struggle to separate signal from noise, leading to missed threats and breaches. 45 different security solutions survey This rising tide of alerts threatens to drown security teams. A found that security analysts can’t deal with 67% of the daily alerts they receive. Most alerts are false positives and not worth the time. study by Vectra AI New cybersecurity vendors like Kivera are pioneering preventative approaches to cloud security. Rather than just detecting threats, before they happen to reduce the number of alerts in the first place. This prevents issues upfront rather than reacting after the fact. Kivera stops misconfigurations The Root Cause of Most Cloud Breaches The root cause behind most cloud breaches is misconfigured resources and permissions. Research suggests will result from customer misconfigurations by 2025. Cloud environments are incredibly complex, with thousands of services and configuration options. Just one mistake can leave an opening for attackers to exploit. 99% of cloud security failures All those misconfigured cloud resources trigger floods of policy violation alerts. But detecting problems after they occur is too late. The damage is already done. Attackers move quickly to take advantage of any slip-up. By the time an alert is triggered, sensitive data may have already been stolen. That's why forward-thinking organizations are shifting to preventative security controls. The traditional reactive model of detect-alert-respond is simply unsustainable. Prevention stops mistakes and policy violations before they ever happen. The Limitations of Detection-Focused Tools Cloud-native security tools on the market today focus heavily on detection and response. These tools are valuable layers of defense but come with inherent limitations: Cloud security posture management (CSPM) solutions from vendors such as Wiz and Orca continuously monitor cloud configurations and permissions. They identify resources that violate security policies or best practices. But again, problems are only detected after misconfigurations occur. The latest evolution in cloud security is cloud-native application protection platforms (CNAPP). Companies like Sysdig and Palo Alto Networks provide CNAPPs that combine security tools such as CSPM and CWPP with code scanning for cloud security. While these platforms embed security in code and templates, they face limitations in infrastructure-as-code scanning, restricted to specific programming languages. Kivera overcomes this by operating at the API level, offering a more universal and adaptable security solution.\ However, CNAPPs still rely heavily on threat detection and response. They aim to identify anomalies in cloud applications and resources. However, gaps that allow the attacks in the first place are not directly addressed. The Preventative Security Model The limitations of these detection-focused tools highlight the need for a preventative approach to cloud security. The ideal security model employs a mix of preventative and detective controls, commonly referred to as the “layered security model.” Preventative controls stop policy violations and misconfigurations before they happen. Rather than reacting to events, preventative controls proactively enforce security requirements within systems. Prevention provides a first line of defense to maintain a strong security posture. Detective controls then provide a second line of defense to identify threats that make it past the preventative line. Detective controls are still vital for monitoring, investigation, and incident response. Historically, implementing detective controls in a preventive manner has been challenging, but new tools provide an effective solution to enforce these common detective controls preventively, enhancing overall security posture. Why We Need Preventative Cloud Security This is where preventative approaches to cloud security become essential. Adopting such methods involves deploying inline security measures between users and the cloud. As deployment requests are made, these security systems analyze them against configured security policies. Any requests that violate these policies are immediately blocked, ensuring that only compliant resources are created. This approach emphasizes prevention over detection, eliminating the flood of policy violation alerts by avoiding misconfigurations in the first place. Security teams can then concentrate on real incidents rather than addressing misconfiguration. Vendors like are at the forefront in this area of cloud security. Kivera's solution allows customers to define flexible guardrails and policies tailored to their organization's needs. It then enforces these policies in real-time as users interact with the cloud, preventing misconfigurations at their source and avoiding reactionary measures after the fact. Kivera Best practices for implementing a prevent-first strategy include phasing in prevention by starting with the highest-risk misconfiguration threats and then incrementally expanding policies. Prevention should also be combined with detection tools for layered defenses to catch novel threats while tuning alerting to focus only on critical issues not prevented outright. Processes and training must align with prevention, emphasizing configuring policies over correcting violations. And any violations that still occur should be regularly reviewed to identify and address gaps in coverage. The Future of Cloud Security Today's cloud-first world demands a new approach to security. The volume and pace of threats have rendered traditional reactive models ineffective. Organizations need to prevent threats upfront before damage occurs. The future of security is prevention combined with detection. Organizations still need layered defenses to catch evolving threats. But prevention must come first to establish a robust security posture.

The Missing Piece in Cybersecurity: Tools that Go Beyond Issue Detection

The Certified Kubernetes Security Specialist (CKS) exam is the most challenging in the lineup of practical Kubernetes exams from CNCF.  I won't delve deep into its specifics here, as the Internet is full of relevant information.  It's worth saying that only those candidates who have passed the Certified Kubernetes Administrator (CKA) exam successfully  are eligible for the CKS exam. The topics required for the exam can be found . Additionally, proficiency with tools like falco, sysdig, and trivy is essential. You need to keep in mind that the Kubernetes cluster version used in the exam is updated following the release of each new Kubernetes version, and the delay between the release of a new Kubernetes version and the exam's version update usually does not exceed two months. here Preparation: Initial Steps and Unexpected Hurdles My preparation began two years ago with a course on . However, after two months, I had to interrupt my studies due to family circumstances. When I returned to my preparation some time later, I was faced with the necessity to move to another country. Due to it I had very little time for my studies, and I decided to take the exam without proper preparation. As expected, my first attempt was unsuccessful. kodekloud.com Next, I turned to the course offered by , but I found its content too sparse for independent preparation. Following the community's advice, I purchased a course from , which eventually proved to be the most beneficial, especially in the practical aspect. linuxfoundation.org killer.sh Nevertheless, a number of questions in the simulator were limited, and most of them did not provide a full picture of the possible exam tasks. This prompted me to create my own exam emulator based on AWS EC2 spot instances, using Terraform and Terragrunt. killer.sh CKS Simulator: Birth and Growth While developing the simulator, I managed to prepare for the exam and passed it. It happened on the second attempt due to technical problems from the examination center. After having passed it, I decided to share my experience and tools. It  led to the creation of the CKS Simulator project. Since then, 9 other professionals have joined the project. At present some of them are helping to update the database with exam questions, while others are assisting with documentation and the release of new versions. We are actively gathering feedback from those who've taken the exam to improve our simulator continuously. Mastering the CKS Exam: Insights and Tips For the examination, candidates connect through a secure browser to a virtual machine's desktop (similar to VNC). You won't have access to your browser bookmarks. Within this virtual machine you can launch as many terminals as you like and access the allowed documentation. However, remember that you can only have one page open at a time. It’s common to have problems with exam infrastructure. They include slow terminal responses or connection issues. If you encounter any such difficulties, immediately contact the support, and they'll reschedule your attempt. Having connected to this virtual machine, you'll find connections pre-configured for approximately 16 Kubernetes clusters. As a rule, each exam question utilizes its cluster. Questions vary in their point values, usually ranging from 1 to 12 points. Time management is crucial in this exam. As experience shows each point corresponds to roughly 1.1 minute. So, if a question is worth 4 points, try not to spend more than 5 minutes on it. If it takes longer, mark the question and move on to others, returning to it after you've seen all the remaining questions. Aim to use imperative commands as much as possible, such as for creating pods, deployments, secrets. Save manifests from these commands, edit the obtained manifests, and apply them to the cluster. The virtual machine's terminal has the alias set up. Make use of it, and also use the auto-completion feature (Tab key). Prioritize using the 'help' feature of console utilities whenever possible, as searching through the browser can be time-consuming. k=kubectl How the Simulator Works: The simulator sets up a VPC (Virtual Private Cloud), subnets, 10 Kubernetes (k8s) clusters with prepared resources, and a work-PC with tests for validation. To create exam infrastructure we use Terraform modules as templates. Terragrunt manifests consist of some modules and their parameters. Terragrunt executes these manifests and creates all the necessary exam infrastructure. The module handles network creation. vpc The module manages the creation of SSH keys. ssh-keys sets up a k8s cluster with specific parameters, such as the k8s version, EC2 node type, the number of worker nodes, their labels within the k8s cluster, and runtime ( , , ). k8s_self_management containerd cri-o containerd_gvisor The module is responsible for creating the work-PC. work_pc For convenience, all launch scripts have been added to a Makefile. To set up a new mock exam, you just need to execute the command , and to remove it . TASK=01 make run_cks_mock TASK=01 make delete_cks_mock Once the exam is set up, the script's output will provide you with the IP address of the work-PC. You log into it and complete the assignments. To check the remaining time for the exam, use the command, and to evaluate the assignments, use . time_left check_result For a detailed guide you can refer to the or watch the . documentation video tutorial Resources and Future Plans Currently, we have ready-made Terraform modules for scenario creation, lab works, and simulators for CKS and CKA exams, as well as video materials. We are planning to develop the simulator for the CKAD exam and lab works for AWS EKS in a very short time. : The Most Effective Path to Passing the CKS Exam Purchase the exam during discount periods. For example, during Cyber Monday, discounts can exceed 50%. I recommend buying and going through Kim Wüstkamp's course. Dive into all the theoretical materials and complete the practical assignments provided in the course. Upon purchasing the course, you'll gain access to a Slack channel. Here, you can pose questions to the course author and interact with other participants who are also preparing for the exam or have recently passed it. It's an excellent opportunity to learn about new exam questions and add them to your simulator. Regularly take the mock exam on our simulator until your final score consistently reaches 90% or above. Complete the mock exam on the platform. Its user interface closely mirrors the real exam, which will help you get accustomed to the format and prepare better . killer.sh After going through all these preparatory steps, you'll be ready to tackle the actual CKS exam. Conclusion If our project draws your interest, join us on or our . We always welcome new members and their feedback. We hope our platform will assist many engineers in passing the CKS and other IT-related exams successfully. GitHub YouTube channel If you have any changes or additions to share, please let me know!

The Path to Passing the CKS Exam: From Challenges to Creating a Simulator

For mature enterprises, planning, building, and managing foundational cloud technology platforms accelerate value for their internal clients. Once these enterprises reach a certain size and level of dependency on technology, establishing these foundational platforms help eliminate complexities, boost the effectiveness of its use base, and help adhere to compliance standards across the enterprise. Building these foundational platforms as a SaaS (Software as a Service) enables organizations to maximize their client experience and Return on Investment (ROI). Here is a sample that breaks down the path to SaaS success into four distinct phases (Business Planning, Product Strategy, , and Launch/Go-To-Market), each representing a critical stage in the move to SaaS. SaaS Journey Framework Minimum Viable Service At a broad level, SaaS Journey Framework allows you to accomplish the following: Articulate the compelling factors for bringing up a Platform as a Service, the Target market within the organization, and the potential customer segments. Have a strategy that articulates a clear set of capabilities/offerings that target specific personas within the consumer base. Identify critical capabilities for your Minimum Viable Service (MVS), and set clear definitions and expectations of the launch, timelines, target customers, and how you will engage potential customers to capture feedback. Before you launch, establish a Customer Advisory Board (CAB) to ingest voice-of-customer feedback and prioritize an appropriate sense of urgency; create measurable product adoption expectations. In the rest of the sections, we will get into each key pillar of success, as you build out your Cloud Platform as a Service. These key pillars of success can both be treated as a set of design principles and also as recipes for success. Content Overview Multi-Tenant Experience Control Plane Tenant Workloads Isolation On-boarding and Identity Foundation Self-Service CI/CD Pipeliness as a Service Centrally Managed Products Security by Default Conclusion Multi-Tenant Experience When you design your Cloud Platform for housing multiple tenants, you may want to take advantage of the economies of scale that come with . Simultaneously, the tenants require sharing infrastructure resources across tenants some of the resources to be dedicated to them. Different SaaS models such as Silo, Pool, and Hybrid provide different levels of multi-tenant experience and workload isolation. The silo model refers to an architecture where tenants are provided with dedicated resources. For example, each tenant of your cloud platform may have their own AWS account, that’s vended from a master aws organization’s account. Silo: The pool model refers to an architecture where tenants share resources. These resources typically belong to the base infrastructure. For example, networking services in aws such as NAT Gateway or VPCs could be shared across all your tenants. Pool: The hybrid model refers to an architecture where some resources of your platform are implemented in the Silo model and some in the Pool model. Hybrid: This pattern acknowledges the reality that you cannot exclusively design for Silo or Pool. In scenarios where you must comply with strict workload isolation for teams, choose Silo model. In scenarios where you would benefit from economies of scale (for example, a common set of VPCs, subnets, and NAT Gateway for a set of customers), choose Pool model. Immaterial of which model you choose, each environment managed by your platform still relies on a shared identity, onboarding, and operational experience where all tenants are managed and deployed via a shared construct. This is where a comes in to help. Control Plane based operation Control Plane Control Plane is a management and operations layer that houses central SDKs and CI/CD Pipelines and operates across multiple accounts. It is a critical part of your multi-tenant strategy that ensures that all your Infrastructure as Code pipelines (including On-boarding pipelines) are unified, and managed through a central account (Single Pane of Glass). With Control Plane, you can: Launch Base Infrastructure Resources across multiple hosts (aka accounts) through configuration. On-board teams across all your platform-as-service offerings, through a single, automated, repeated process. Manage platform admin CI/CD Pipelines as products, thus achieving standardization across all admin pipelines. Build standard Admin Deployers that enable you to provide CI/CD Pipeline as Services. Tenant Workloads Isolation When you build and operate a multi-tenant platform as a service, you must ensure that . each tenant is prevented from accessing another tenant’s resources The following strategies help in enforcing workloads isolation: ABAC is an authorization strategy that defines permissions based on attributes. For example, you can enforce a policy that allows permissions to a user only when the user’s matches the resource’s Attribute-Based Access Control (ABAC): team name tag team name tag. All resources in your cloud provider may not support ABAC. In such scenarios, the NBAC strategy additionally helps you to enforce permissions to a team based on resource naming convention. For example, you can enforce a policy that allows permissions to a user only when the resource starts with the to which a user belongs. Use this as a complementary strategy on & above ABAC. Name-Based Access Control (NBAC): team name In AWS, IAM Policy Conditions element and IAM Policy Resource element are excellent ways to enforce both ABAC and NBAC. Beyond tenant workloads isolation, ABAC (using Tags) also allows you to measure the cost impact of individual tenants. Designing multi-tenant experience for your platform as a service requires deliberate planning. The above patterns and techniques (Silo/Pool/Hybrid, Control Plane and Authorization strategies) should help you in coming up with a robust design. On-boarding and Identity Foundation There are several channels (sign-up page / GitHub Pull Request etc.) through which you may want to onboard tenants for your platform. Most often, tenant onboarding is initiated directly by tenants, but this could be a provider-managed process too. Immaterial of the channel, this step often requires the orchestration of a number of components to successfully provision and configure all the elements needed to create a new tenant. For example, let’s take a scenario where we have decided on our authentication strategy as IAM with MFA. When a Team (composed of a set of users) is on-boarded, the platform may perform the following steps: Create for each user within a team & attach the tag to the user with an appropriate value. IAM User team name Attach IAM User to one or many , depending upon the attached to the user in the request. IAM Groups persona Create with appropriate permissions that underlying cloud services will use for execution. For example, the platform may create separate Team Execution Roles for SageMaker & Glue. Team Execution Roles Create AWS SNS Topic for a Team as well as for each user. These topics can then be used for sending notifications to the team or a user. Attach that govern platform usage across all users. For example, mandate MFA before any service is accessed through Console or CLI. common policies By pre-packaging all preventive permissions and team-specific resources (like execution roles) during on-boarding, you can deliver a secure, governed yet easy-to-use and repeatable on-boarding process that just works. Self-Service Self Service is a key pillar that unlocks by empowering consumers to launch cloud resources and pipelines with little or no intervention from administrators. accelerated delivery Enabling Self-Service on Cloud Platforms is hard since you need to simultaneously satisfy two goals that are seemingly contradictory: On the one hand, you need to provide flexibility to end users. On the other hand, you require your cloud resources to be secure and compliant. AWS offers a couple of interesting models for self-service that you can embrace. CI/CD Pipelines as a Service Pipelines as a Service offers a toolchain standard to be re-used by application teams. In this model, end-user teams launch a governed deployment pipeline from AWS Service Catalog. CI/CD The workflow for this model is as follows: Cloud platform engineers develop a . service catalog product A product comprises one or more AWS resources and is created by designing AWS CloudFormation templates that combine resources, their relationships, and the parameters that the end user can plug in when they launch the product. For example, a CI/CD Pipeline Service product may create an AWS CodePipeline project that connects with a GitHub Repository branch (plugged in by end-users) for the followed by a which invokes a Lambda Deployer Function that performs the required deployment. source stage, deploy stage, The input to the Lambda Deployer function comes from a configuration file, which is supplied by end-users. DSL The launch of a product just creates a fully functional CI/CD Pipeline. Now, whenever end-users push the DSL configuration file & any other associated required files into the GitHub Repository branch, the CI/CD Pipeline kicks off and the Lambda Deployer function performs the deployment & also notifies the end-user through Team SNS Topic. Key Benefits: End-users are provided with the flexibility to specify configurations & details pertaining to the deployment (flexible), but admin takes care of the actual deployment to the cloud (standardization and compliance) Standard deployers, but flexible configuration: Every deployment of a resource by the consumer team is forcefully driven through the . Further, this follows a full-fledged way of implementing Continuous Delivery for cloud-native applications. GitOps & DSL driven: GitHub repository PR-Merge process GitOps Eliminates individual personnel dependency https://twitter.com/kelseyhightower/status/953638870888849408?s=20&embedable=true Centrally Managed Products This model allows end-user/consumer teams to provision resources managed by a central operations team . as self-service In this model, Cloud platform engineers publish infrastructure portfolios to AWS Service Catalog with pre-approved configuration. This locks down how infrastructure is configured and provisioned. For example, consider offering In this case, the workflow would be as follows: S3 Bucket as a Service. Cloud platform engineers design and create a CloudFormation template, with appropriate end-user parameters such as team name, bucket name, etc. They pack in all required security and compliance requirements (No Public ACLs, enforce in-transit and at-rest encryption, etc.) They add required tests and DevSecOps validations. They roll out this as a Service Catalog Product. When end users launch this product, they receive a fully secure and compliant resource that is locked down to their team. Key Benefits End users are NOT provided elevated benefits. They must use Service Catalog products to launch resources. Principle of least Privilege: All resources created through Service Catalog exhibit thus accomplishing standardization and compliance. Standardization & Compliance: the same behavior, With models, platform admins can provide superior self-service to end-users while adhering to the highest levels of security, standardization, and compliance. Centrally Managed Products & CI/CD Pipelines as a Service Security by Default Security is a key pillar that provides multi-fold benefits, especially when you are launching a platform as a service. Building all capabilities and services with principle ensures that hundreds of teams in your organization use these products, . Security by default without worrying about managing security in the cloud Below are a few strategies to ensure that platform offerings are secure by default: A strong Identity Foundation that is either built with MFA (or) Single Sign-on, and a Teams construct that ensures that workloads are appropriately tagged and authorized. A preventive permissions model that protects cloud resources across all channels (console, CLI, programmatic access) and also enforces . team permissions A carefully designed Tenant Workloads isolation through Attribute Based Access Control (ABAC) and Name Based Access Control (NBAC) ensures teams can access only what is theirs. A Control Plane architecture that ensures that all products and pipelines are launched into accounts from a central account (single pane of glass). A carefully enforced data encryption standards (transport layer & at-rest) while launching products through , through appropriate configuration. Centrally Managed Products & CI/CD Pipelines as a Service Built-in DevSecOps controls through standard libraries like Checkov, which are codified at the source, and automated for efficiency. Integrated container security during Continuous Integration with tools like sysdig. A hardened security posture for externally exposed services with appropriate controls such as CloudFront, Web Application Firewall (WAF), API Keys, and Usage Plans. Enforce standard tags across all resources launched (including admin resources) for attribution, security, and FinOps. By establishing preventive guardrails, including DevSecOps in all builds, protecting data privacy in the capabilities offered, and isolating team workloads, you can deliver an exceptional security by default that works for teams at scale. Conclusion Cloud Platforms as a Service provide agility and innovation to mature organizations. By treating them as full-fledged SaaS services with the help of the SaaS journey framework, and also coming up with a solid architecture with the help of the above-mentioned pillars, organizations can unlock exceptional service experience and also increase agility. “Platforms and platform thinking aren’t cure-all solutions. They’re conduits and catalysts for your strategic goals. To harness their full potential and realize their full value, they must be designed and built with your unique goals in mind.” — Rachel Laycock, Global Managing Director, Enterprise Modernization, Platforms and Cloud References Realizing the potential of platforms SaaS Journey Framework — One Minute White Paper SaaS Journey Framework Accelerate Deployments on AWS with effective governance Platform Engineering Product Teams Realizing the potential of Platforms The enterprise guide to platform thinking Also published here.

Building Cloud Platforms as a Service — Key Pillars of Success

335 Stories To Learn About Serverless

Many enterprises that implement Kubernetes don’t realize how insecure it can truly be out of the box — and even when they do, they’re not sure what to do about it. And since Kubernetes is an extremely complex and flexible tool that in production can consist of hundreds, if not thousands, of moving parts — understanding the vulnerabilities of Kubernetes, potential solutions, and relevant regulations and trends can be a time-consuming and daunting task. For most any business, this makes it way too easy to introduce serious legal or security issues into their clusters and production applications. With KubeCon Europe 2023, I was impressed with (and happy to see) the number of security solutions entering the market. Continuing from 2022, the biggest theme from KubeCon Europe 2023 was software supply chain security — ensuring that you know what’s running in your cluster and that it’s vulnerability free. I was struck then, as I have been in recent years, by the importance of software supply chain security. With cloud-native apps, containerization, and Kubernetes, today’s software organizations are in an arms race with malicious attackers who seek to undermine and poison our software. So I was pleased to come across several additional projects at KubeCon Europe 2023 that are dedicated to tackling the challenge of Kubernetes security. In this article, I’ll give a whistle-stop tour of those projects. But let’s start with a quick overview of the conference and what I consider to be the most important aspects of k8s security. Breaking Down Kubernetes Security First, the conference. I was a little worried that the IT recession might mean the conference wouldn’t be as meaningful as in past years — but I’m happy to say that I had no need to worry! While I wasn’t able to attend in person, through remote and post-conference conversations with those that were there, the conference seemed to be as exciting as ever! While there weren’t any standout new trends at the conference, there was a ton of tooling and discussion around Kubernetes security. To keep everything straight in my mind, I categorize k8s security into three particular aspects: attestation, provenance, and SBOM: Attestation: Confirming your artifact’s origin and that it is what it claims to be. Attestation typically comes in the form of signing containers, packages, and so on, in a way that the receiving party can verify. Provenance: The audit trail of where the artifact came from and who had interactions with it. Often used in connection with attestation if something doesn’t look right. Software bill of materials (SBOM): What are the packages and dependencies inside the artifact? These are increasingly necessary for regulation and as a demonstration to customers. With that in mind, let’s walk through the solutions. OpenClarity consists of a suite of tools that aim to bring insights into different levels of the cloud-native stack, from security to observability. OpenClarity The two relevant components to this post are KubeClarity and VMClarity which create SBOMs and perform vulnerability analysis for Kubernetes clusters and virtual machines respectively. runs on any Kubernetes cluster and provides a UI and CLI for analyzing images and generating SBOMs. By default, KubeClarity doesn’t have its own SBOM generator or vulnerability scanner, but instead, supports third-party tools that you can enable in any combination, making it great for adding additional interfaces for existing toolchains. KubeClarity If you would rather not install each of the components yourself, then they’re commercially available as part of . Cisco Panoptica Support includes the following SBOM generators and vulnerability scanners: Syft CycloneDx-gomod Trivy Grype Dependency-Track We’ll cover some of these projects in more detail below. works similarly but within the context of VMs used by cloud services to host containers and clusters. Compared to containers, VMs may be as (or even more) vulnerable to threats and they typically need complex tools for analysis. VMClarity Following a similar pattern to KubeClarity, VMClarity supports aggregating multiple tools into one UI and CLI. in-toto is an open-source project that focuses on the attestation part of software supply chain security. You use it to define a “layout” for a project, i.e., how the different components should fit together. in-toto A project ships this definition with its code, and then another user of that software can compare what they have with the attached definition to see if it matches the structure and contents they expect. If it doesn’t, then this could point to external tampering or other issues. Trivy is a mature and comprehensive open-source tool from Aqua Security that supports scanning multiple sources, from file systems to containers and VMs. Trivy also looks beyond vulnerabilities, to scan licenses, secrets, infrastructure as code misconfiguration, and more. Trivy It supports different SBOM output formats, attestation using in-toto, as well as scanning the attestation for vulnerabilities. To tie all these features together, Trivy has an ecosystem support, complete with IDE plugins, CI/CD, and a Kubernetes operator. Slim.ai Historically, aimed to help you understand the contents of an image and how to “slim” it down to the essentials. The platform has now expanded its feature set to include vulnerability scanning. Slim.ai Slim.ai presents the data in a more user-friendly way than many of the other tools in this post. On top of its open-source for identifying the contents of an image, Slim.ai uses Trivy for vulnerability scanning. SlimToolkit You can then use the “harden” feature to create a new version of the image that’s removed any vulnerabilities and extraneous packages. The Update Framework A common reason behind insecure software is out-of-date package versions, but how do you trust that an update is what it says it is and won’t cause you more problems? Release signing—or attestation—was a hot topic at KubeCon among vendors, with many offering their own solutions. One in particular that stood out was CNCF’s recently graduated (TUF). The Update Framework Confusingly named, it’s not a framework, but a specification that developers can follow when implementing their update systems to help users know they can trust the updates they receive. There’s also a . Python reference implementation Syft is a popular open-source CLI tool created by for generating an SBOM from container images and filesystems. It’s designed to provide a catalog of dependencies for other tools to use as a data source. Syft Anchore It supports many popular programming languages, package managers, and container image formats. With its support for different SBOM file formats and custom templates for reports, Syft has become an ideal component for vulnerability scanning toolchains. Grype is another popular open-source tool from Anchore. Working with SBOM files, Grype scans container images and filesystems for vulnerabilities. Grype supports different output formats for vulnerabilities and custom templates for output. Grype sigstore is another suite of tools that focuses on attestation and provenance. Within the suite are two tools I heard mentioned a few times at KubeCon: and . sigstore Cosign Rekor Cosign is used for signing containers through a variety of different methods. It has strong integration with other open-source tools, such as . Kyverno Rekor is a tamper-resistant ledger for metadata generated by a software supply chain project. This means that parties can query the metadata to help them make decisions based on decisions previously made by others. It’s not a very well-known project, but it is growing in popularity. Kubescape is a comprehensive Kubernetes security platform and CNCF sandbox project. It can scan clusters, Helm charts, and YAML manifests to detect misconfigurations. It supports various frameworks, including , , and the . Kubescape NSA-CISA MITRE ATT&CK® CIS Benchmark Chainguard Taking a very definite enterprise approach, is impossible to try without first speaking with their sales department. But as far as I can tell, it consists of two main products. Chainguard Chainguard Images are specialized, hardened images that focus on a minimal footprint, promise no vulnerabilities, are as small as possible, and ship with SBOMs. Chainguard Enforce combines the creation of policies for your software supply chain with the enforcement of those policies. You write policies in YAML or by using a CLI tool to configure a Kubernetes agent that reports back to the service. You can view reports via the CLI or a GUI. Policies can include image signing, SBOM inclusion, and more. Chainguard also appears to have several . The most popular one is , used for building OCI images from APK packages. open-source projects apko Falco is a well-known open-source security solution originally created by Sysdig. It’s a CNCF incubating project and one of the few (as far as I can tell) options on this list that uses eBPF to scan for vulnerabilities. Falco This does mean it needs a few extra steps to install, and you can only test it on Linux systems. However, once you have Falco set up, it runs more performant than any container agent and can detect vulnerabilities at all system levels. The Future Is Complicated I hope you enjoyed this overview and found a few tools that will help you secure your enterprise. Most experts believe that cybersecurity will become more complex and challenging as more aspects of the world are dominated by software: IoT, smart cars, and drones—and now, we’ve added AI and LLMs to the mix. The arms race between attackers and defenders doesn't seem to favor the defenders. And deploying solutions is a complicated endeavor. Now is a good time to find the tools and workflows that suit you and your organization before you become the target. Have a really great day!

An Overview of Kubernetes Security Projects at KubeCon Europe 2023

Organizations now recognize the significant role of integrating security in the software development lifecycle. DevSecOps is a powerful approach that has emerged to achieve this goal. By incorporating security practices at the earliest stages of development, DevSecOps helps organizations identify and reduce vulnerabilities more effectively, minimize the risk of security breaches, and build more secure applications. This article will discuss the fundamental principles of DevSecOps and provide key steps for securing your organization’s CI/CD Pipeline. DevSecOps Principles : Organizational principles It is important to involve Security teams right from the beginning of a project to make sure that security requirements are given serious thought and attention early on. This step can prevent the discovery of security problems later in the development phase, which could be more expensive and time-consuming to fix. Involve Security Teams Early: In DevSecOps, it is important for Development, Security, and Operations teams to work together. By promoting a culture of shared responsibility for security, organizations can ensure that all team members play a part in creating secure applications and in identifying and solving security issues faster. Collaboration and Transparency: DevSecOps incorporates security practices early in the development process, also known as "shifting left." It helps organizations to detect vulnerabilities in the codebase before they escalate into expensive and time-consuming issues. Shift-Left: DevSecOps advocates for the inclusion of security procedures throughout the entire software development process, ensuring continuous security. This involves implementing automated security testing, constant monitoring, and regular security evaluations. Continuous Security: The concept of security chaos engineering involves deliberately introducing security-related problems and disruptions into a system to verify its ability to withstand them and reveal weaknesses. Security Chaos Engineering: By replicating actual security incidents, organizations can obtain significant insights into their system's performance during challenging conditions. This enables them to take proactive measures to address vulnerabilities and enhance their overall security position. Security Awareness/Training principles: To make security a top priority of your organization, provide your team members with security training and resources, encourage collaboration, and recognize that everyone is responsible for security. By doing this, you can cultivate a culture that prioritizes and integrates security throughout your organization. Foster a Security Culture: Developers should be encouraged to adopt secure coding practices like input validation, output encoding, and proper error handling. These practices will help mitigate security vulnerabilities in the code and reduce the risk of potential attacks. Adopt Secure Coding Practices: Gamification techniques can be adopted by organizations to encourage a security-focused culture and educate team members on security best practices. Gamification of Security Training: By transforming security training into an enjoyable and competitive experience, engagement and knowledge retention can be enhanced, ultimately promoting better security practices throughout the organization. Technical principles: Automating security processes can bring various benefits to organizations. These include increased efficiency, reduced human error, and the consistent application of security best practices. Automation: To maintain security during the development process, it is important to regularly run security checks and tests within the continuous integration and continuous deployment pipeline. This will ensure that security concerns are constantly evaluated and addressed. Integrate Security into the CI/CD Pipeline: Use tools like static application security testing (SAST) and dynamic application security testing (DAST) to check for weaknesses and potential security threats in your codebase. These automated security testing tools should be added to your organization's CI/CD pipeline to provide real-time security feedback. Implement Automated Security Testing: Securing the CI/CD Pipeline: Key Steps and Solutions To secure your CI/CD pipeline, protecting the Build environment is the first essential step. Only authorized personnel should access Build servers and infrastructure. To prevent unauthorized access, implement robust authentication methods, such as multi-factor authentication (MFA) with hardware keys. Additionally, keep the Build environment up to date with the latest security patches, and configure it according to the best industry practices. Secure the Build Environment: To safeguard your code repository, implement robust access controls that permit only the necessary access to authorized personnel, and monitor it frequently to identify any suspicious activities. Also, keep reviewing and updating user permissions and use encryption to protect sensitive data stored in the repository. Secure Code Repository: Hardcoded credentials, such as passwords or secret keys within the code, is a serious security risk as they can provide unauthorized access if the code is exposed. Hardcoded Credentials Scanner Solutions: Open-source solutions: TruffleHog - https://github.com/trufflesecurity/trufflehog - GitLeaks https://github.com/gitleaks/gitleaks - GitSecrets https://github.com/awslabs/git-secrets Enterprise solutions: GitGuardian - https://www.gitguardian.com/ SpectralOps - https://spectralops.io/ Bridgecrew - https://bridgecrew.io/secrets-scanning/ To automatically detect any potential security weaknesses in your code during the build process, integrate SAST tools into the CI pipeline. These tools can help you find problems such as insecure coding practices, input validation errors, and potential code injection vulnerabilities. Static Application Security Testing (SAST): Open-source solutions: SonarQube - https://www.sonarsource.com/products/sonarqube/ Semgrep CLI - https://github.com/returntocorp/semgrep Enterprise solutions: Veracode - https://www.veracode.com/products/binary-static-analysis-sast Checkmarx - https://checkmarx.com/cxsast-source-code-scanning/ - Coverity https://www.synopsys.com/software-integrity/security-testing/static-analysis-sast.html To ensure the security of your application, you can use SCA tools to track third-party libraries and open-source components that you use. SCA tools can check for potential security risks such as outdated components, known vulnerabilities, and licensing issues. Software Composition Analysis (SCA): Open-source solutions: OWASP Dependency-Check - https://owasp.org/www-project-dependency-check/ - Nancy (GoLang) https://gonancy.dev/ - RetireJS (JavaScript) https://retirejs.github.io/retire.js/ - Safety (Python) https://github.com/pyupio/safety Enterprise solutions: - Black Duck Hub https://www.synopsys.com/software-integrity/security-testing/software-composition-analysis.html Mend - https://www.mend.io/sca/ Snyk - https://snyk.io/ In case your software uses containers, make sure to follow container security best practices, which include implementing minimal base images, scanning for vulnerabilities, and enforcing strict access controls. Additionally, it would be best if you used specialized container security tools, like container vulnerability scanners and runtime security monitoring solutions. Container Security: Open-source solutions: Trivy - https://github.com/aquasecurity/trivy - Grype https://github.com/anchore/grype - Clair https://github.com/quay/clair Enterprise solutions: Aqua Security - https://www.aquasec.com/products/software-supply-chain-security/ Sysdig Secure - https://sysdig.com/products/secure/ Snyk - https://snyk.io/product/container-vulnerability-management/ Incorporate security checks into your use of IAC tools like Terraform, CloudFormation, or Ansible. This is to ensure that the configuration of your infrastructure is indeed secure and free from potential security misconfiguration. Infrastructure as Code (IaC) Security: Open-source solutions: Checkov - https://github.com/bridgecrewio/checkov Tfsec - https://github.com/aquasecurity/tfsec KICS - https://kics.io/ Enterprise solutions: Bridgecrew - https://bridgecrew.io/infrastructure-as-code-security/ Prisma Cloud - https://www.paloaltonetworks.com/prisma/cloud/infrastructure-as-code-security - Snyk https://snyk.io/product/infrastructure-as-code-security/ To test your application in a real-time environment, add DAST tools to your CI/CD pipeline. These tools can uncover vulnerabilities that may only become visible when the application is executing, such as configuration issues, authentication problems, and access control concerns. Automated DAST tools should be used for thorough security testing. Dynamic Application Security Testing (DAST): Open-source solutions: OWASP Zed Attack Proxy (ZAP) - https://www.zaproxy.org/ - Nikto https://github.com/sullo/nikto - GoLismero https://github.com/golismero/golismero Enterprise solutions: Fortify WebInspect - https://www.microfocus.com/en-us/cyberres/application-security/webinspect Rapid7 InsightAppSec - https://www.rapid7.com/products/insightappsec/ - Checkmarx https://checkmarx.com/checkmarx-dast/ To enhance the security of your application and infrastructure, it is essential to continuously track and analyze their behavior. This can be achieved by implementing solutions for constant monitoring and logging. By doing so, you can quickly identify and respond to any potential security incidents that might occur. Continuous Monitoring and Logging: To facilitate this process, tools like SIEM (Security Information and Event Management) systems, intrusion detection systems, and log analyzers can be used to detect and alert you on security events. Open-source solution: ELK Stack (Elasticsearch, Logstash, and Kibana) - https://www.elastic.co/ Enterprise solutions: Splunk - https://www.splunk.com/en_us/products/enterprise-security.html Datadog - https://www.datadoghq.com/ To maintain the security and adherence of your CI/CD pipeline to industry standards and regulations, it is essential to conduct regular security audits and assessments. This includes examining the code, testing for potential vulnerabilities, and assessing the infrastructure. By implementing these measures, you can ensure that your pipeline is secure and compliant. Regular Security Audits and Assessments: Open-source solutions: OpenVAS - https://github.com/greenbone/ - BurpSuite Community https://portswigger.net/burp/communitydownload Enterprise solutions: Tenable Nessus - https://www.tenable.com/products/nessus QualysGuard - https://www.qualys.com/cloud-platform/ - BurpSuite Professional https://portswigger.net/burp/pro To be well-prepared for any security breach or incident, it is essential to create a clear incident response plan that lists the necessary steps to take. To ensure the safety of your application, your CI/CD pipeline must have the ability to roll back any deployments, patch any vulnerabilities, and immediately redeploy secure versions of your application. Incident Response Planning: Open-source solution: TheHive Project - https://thehive-project.org/ Enterprise solutions: IBM Resilient - https://www.ibm.com/products/qradar-soar Cortex XSOAR - https://www.paloaltonetworks.com/cortex/cortex-xsoar - D3Security SOAR https://d3security.com/enterprise-soar/ is a beneficial tool for DevSecOps teams. It's an open-source vulnerability management tool created by the OWASP community. Vulnerability Management and Reporting: DefectDojo This tool helps manage security vulnerabilities in the development process. One central space for all the information regarding defects is provided by DefectDojo. It makes it easier for teams to generate detailed reports and keep track of their progress over time. DefectDojo promotes clear communication about vulnerabilities, which ensures that security issues are resolved efficiently and promptly. As you can see, it is crucial to secure the CI/CD pipeline to implement a successful DevSecOps process. To achieve this, organizations need to incorporate security checks and tools throughout the pipeline. By doing so, they can identify vulnerabilities in advance and address them before they can cause security breaches. This helps to ensure that their applications are secure and comply with regulations. With the steps and practices outlined in this article, you can establish a robust and secure CI/CD pipeline for delivering software quickly and safely.

DevSecOps Principles and Key Steps for Securing the CI/CD Pipeline

306 Stories To Learn About Docker

188 Stories To Learn About Containers

The cloud has been a relatively recent major breakthrough in the area of computer science. And most organizations have leveraged its benefits by moving their applications to the cloud. However, everything brings with it some pros as well as some cons. Ensuring the security of the applications stored and executing on third-party servers is a huge challenge. In this article, we will focus on Java and discuss various good practices and tools that enable us to secure Java applications in the Cloud. Scope In this article, we explore the best practices and tools for securing Java applications in the cloud. The article begins by highlighting the importance of securing Java applications in the cloud and the challenges that developers face in achieving this. It then discusses a few best practices for securing Java applications in the cloud, including secure network communication, authentication and authorization, input validation, encryption and hashing, and monitoring and logging. The article also covers various tools that developers can use to secure Java applications in the cloud, including IAM, WAFs, vulnerability scanners, code analysis tools, DevSecOps tools, encryption and key management tools, and container security tools. The article aims to provide a comprehensive overview of the best practices and tools for securing in the cloud to help developers build secure and reliable cloud-based applications. Java applications Securing Java Applications in the Cloud Security is one of the most intricate, extensive, and crucial facets of software development. However, software security is usually disregarded or reduced to merely a few tweaks at the end of the development cycle. The list of significant data security breaches totals 3 billion exposed records per annum, including some big names. If it can happen to them, it can happen to you too. A major contribution to the increasing Security breaches is the migration of applications to the Cloud, because of its distributed nature and involvement of third parties. However, we can utilize some practices and measures to make sure our application is secure on the Cloud as well and exposed to minimal attacks. The good news is that Java has been around for a while and has numerous built-in security mechanisms, being one of the most popular programming languages for developing cloud-based applications. The has undergone rigorous combat testing and is regularly updated to address emerging security flaws. A large variety of tools for profiling and reporting security concerns are also part of the Java ecosystem. Java Security package However, it's crucial to exercise caution even with a reliable development environment. Vulnerabilities might lurk in the background during the complicated process of application development. Securing Java applications in the cloud is a complex task that requires careful consideration of various security risks and the implementation of best practices and tools. Best Practices for Securing Java Applications in the Cloud We present here some practices that are suggested to be incorporated to create secure Java applications in the cloud: Clean Code Maintaining the utmost simplicity in your code without losing usefulness is advised since vulnerabilities like to lurk in complexity. Always write your code to reveal as little information as feasible. Code that is safe and easily maintained benefits from implementation details being hidden. We suggest some points to keep in mind for writing secure Java code: Use Java's access modifiers to your advantage. Your code will be better protected if you know how to specify various access levels for classes, methods, and their attributes. Anything that can be kept private ought to be kept private. The minimal API and interface surfaces should always be defined. Make components interact over the smallest feasible region by decoupling them from one another. Even if a breach just affects a portion of your application, others will still be affected. Avoid exposing Sensitive Information in the Source Code Developers should avoid hardcoding sensitive information such as passwords or API keys in the source code and instead use configuration files, environment variables, or key stores to store and manage such information. All personally identifiable information, such as credit cards, social security numbers, etc., is subject to the above password policy. Your application should exercise the utmost caution while handling any personal information that has been given to it. Implement Authentication and Authorization Authentication and authorization are essential security mechanisms for protecting Java applications from unauthorized access. Developers should implement robust authentication and authorization mechanisms to verify the identity of users, services, and systems that interact with the application. To achieve this, multi-factor authentication, password policies, access control lists, and role-based access control can be implemented. Implement Input Validation Input validation is an essential security practice that helps prevent attacks like and cross-site scripting. Developers should validate all input data received from users and other systems before processing it to ensure that it meets the expected format and does not contain malicious code or characters. This is particularly valid for anything that might be processed by another tool or system. For instance, if something has the potential to become an argument for an OS command line! SQL injection : When programmers build dynamic database queries that accept user input, they introduce SQL Injection risks. Any screen input field may be used by an attacker to insert SQL instructions into the input data. The program then executes the malicious SQL in the database as a result of a flaw in the code. Hence, don't use dynamic SQL, make use of prepared statements (with parameterized queries). Otherwise, never concatenate parameters to create SQL statements, which makes SQL injection attacks quite likely. Prefer putting saved routines to use, and always validate input on the whitelist. SQL Injection Cross-Site Scripting ( ) assaults take place when an attacker employs a web application to distribute malicious code to other users, typically in the form of a browser-side script. Cross-site scripting: XSS To prevent it, use a proven library to HTML encode your output for HTML contexts and filter inputs with a whitelist of permitted characters to keep Java code applications secure. Use JavaScript Unicode escapes for JavaScript. Avoid Serialization In Java, serialization is the process of turning an object into a binary byte stream so that it may be transferred between Java Virtual Machines and then recreated using the deserialization process. Serialization establishes an interface to Java classes by avoiding common field access control techniques like constructors and access modifiers. Remote inputs can therefore be converted into fully functional objects. So, it's crucial to avoid serialization, especially when working with classes that are security-sensitive. This is so that all class fields may be accessed since serializing a class produces a public interface. Always think about which fields are accessible before employing serialization because it may be intrinsically unsafe for the application. It is also said that overloading certain constructors and methods is said to impact the code. Try to avoid that as well. Implement Encryption and Hashing Encryption and hashing are critical security measures for protecting sensitive data in transit and at rest. Developers should use strong encryption algorithms such as AES or RSA to encrypt data in transit and use secure hash algorithms such as SHA-256 or SHA-512 to hash passwords and other sensitive data before storing them in databases or other storage systems. Avoid Exposing Implementation through Error Messages Production error messages might provide attackers with a wealth of data. Particularly stack traces can disclose details about the software you're running and how you're utilizing it. Keep stack traces hidden from end users. As an example, this also includes warnings for failed login attempts. The error message should read "Login failed" rather than "Could not locate that user" or "Incorrect password”, which would otherwise provide hints to the user about the underpinning technology stack and processing. Make sure the information is as hidden as you can. Implement Monitoring and Logging Monitoring and logging are essential security practices for detecting and responding to security incidents in real-time. Developers should implement robust monitoring and logging mechanisms to track application activities, detect anomalies, and generate alerts when security incidents occur. This can be achieved by using tools such as log4j, Logback, or Splunk to collect and analyze application logs.\ Tools for Securing Java Applications in the Cloud The below tools can be utilized to secure applications in the cloud effectively. Identity and Access Management (IAM) IAM is a cloud service that provides authentication and authorization mechanisms for securing cloud resources. IAM helps manage user identities, roles, and permissions, enabling developers to control access to cloud resources such as databases, storage systems, and APIs. and are popular IAM services for securing Java applications in the cloud. AWS IAM Google Cloud IAM Web Application Firewalls (WAF) WAFs are security tools that protect web applications from common attacks such as SQL injection and cross-site scripting. WAFs sit between the application and the user, inspecting incoming traffic and blocking malicious requests. Some popular WAFs for securing Java applications in the cloud include AWS WAF, Azure WAF, and Google Cloud Armor. Vulnerability Scanners Vulnerability scanners are tools that scan applications and infrastructure for security vulnerabilities. Vulnerability scanners identify security weaknesses and provide recommendations for remediation. Some popular vulnerability scanners for securing Java applications in the cloud include Qualys, Tenable, and OpenVAS. Code Analysis Tools Code analysis tools are tools that analyze source code to identify security vulnerabilities and coding errors. Code analysis tools use static code analysis and dynamic code analysis techniques to identify security flaws such as buffer overflows, SQL injection, and cross-site scripting. Some popular code analysis tools for securing Java applications in the cloud include Checkmarx, Fortify, and Veracode. DevSecOps Tools DevSecOps tools are tools that integrate security into the software development lifecycle. DevSecOps tools automate security testing, code analysis, and vulnerability management, enabling developers to identify and remediate security flaws early in the development process. Some popular DevSecOps tools for securing Java applications in the cloud include Jenkins, GitLab, and CircleCI. Encryption and Key Management Tools Encryption and key management tools are tools that enable developers to encrypt data in transit and at rest and manage encryption keys. Encryption and key management tools provide secure storage for encryption keys and ensure that only authorized users can access them. Some popular encryption and key management tools for securing Java applications in the cloud include AWS KMS, Azure Key Vault, and Google Cloud KMS. Container Security Tools Container security tools are tools that provide security for containerized applications. Container security tools monitor container activities, identify vulnerabilities, and provide runtime protection for containers. Some popular container security tools for securing Java applications in the cloud include Aqua Security, Sysdig, and Twistlock. Conclusion Securing Java applications in the cloud requires careful consideration of various security risks and the implementation of best practices and tools. Developers should focus on: Writing a code that encapsulates the implementation and hides the sensitive information from the network. Encryption should be employed in an inevitable case of sharing sensitive information over the network, or otherwise. Authentication and Authorization should be properly implemented to ensure access to the right information to the right person. Validating the input data as well as avoiding serialization to ensure that an external input cannot inject malicious code that takes over the system. This includes preventing SQL injections and Cross-Site Scripting. Monitoring and logging application activities for real-time detection of security breaches. There are several tools available for securing Java applications in the cloud, including IAM, WAFs, vulnerability scanners, code analysis tools, DevSecOps tools, encryption and key management tools, and container security tools. By following best practices and using the right tools, developers can build secure Java applications in the cloud and protect against security threats.

Securing Java Applications in the Cloud: Best Practices and Tools

In this article, we show how to dockerize a NestJS + Prisma application. We go beyond the basics, following the best practices from and . Our final looks like this: Dockerfiles Snyk Dockerfile FROM node:18 as build
WORKDIR /usr/src/app
COPY package.json .
COPY package-lock.json .
RUN npm install
COPY . .
RUN npx prisma generate
RUN npm run build

FROM node:18-slim
RUN apt update && apt install libssl-dev dumb-init -y --no-install-recommends
WORKDIR /usr/src/app
COPY --chown=node:node --from=build /usr/src/app/dist ./dist
COPY --chown=node:node --from=build /usr/src/app/.env .env
COPY --chown=node:node --from=build /usr/src/app/package.json .
COPY --chown=node:node --from=build /usr/src/app/package-lock.json .
RUN npm install --omit=dev
COPY --chown=node:node --from=build /usr/src/app/node_modules/.prisma/client  ./node_modules/.prisma/client

ENV NODE_ENV production
EXPOSE 3000
CMD ["dumb-init", "node", "dist/src/main"] Now, let's start from the basics and improve our Dockerfile. 1. Basic Dockerfile The simple, starting, dockerfile that we can create is from the following: FROM node                           # Use basic node image
WORKDIR /usr/src/app                # Set working dir inside base docker image
COPY . .                            # Copy our project files to docker image
RUN npm install                     # Install project dependencies
RUN npx prisma generate             # Generate Prisma client files
RUN yarn build                      # Build our nestjs
EXPOSE 3000                         # Espose our app port for incoming requests
CMD ["npm", "run","start:prod"]     # Run our app The previous Dockerfile would generate a valid image and no problems. It will use the latest node image (Node v18 at the time of writing) and run our app. 2. Adding .dockerignore to our project We want to be sure that we aren't leaking any sensitive files to our docker image. In particular, during the command . If we are running this from a CI pipeline, that has just downloaded the repository. Hopefully, we are being careful and there isn't any credential leaked into git. So, no consequences to our docker image. COPY . . But, during installation, we could have some more complex workflows and generate some sensitive files. Either that, or we build our image locally to share or test it. Best to be sure we have a file preventing that. .dockerignore It could have something like this: .dockerignore   # Ignore the ignore
node_modules    # Ignore local node_modules folder
npm-debug.log   # Debug files
Dockerfile      # The dockerfile
.git            # The git history
.gitignore      #
.npmrc          # If accessing a private npm repository here will be the token used, so ignore to prevent leaking
.env-*          # Any other environment that we don't want to include
.gitlab-*       # Deploying with gitlab ?
.github         # Using github actions ?
*.md            # Any 3 Creating a multi-stage image Optimizing our image, we can benefit from using a multistage docker image, reducing image size (which cost us money in some environments like , and also saves us bandwidth and time during deployment). AWS ECR We can install our packages and build the application in one step. Then use another image, copy the generated build files, and install only the production dependencies. For the build step, we could continue with the base node image used so far. We ideally want to use the same version of tooling during all steps, the same node version, underlying OS, and packages. We could go on listing all details using a specific image tag like or not use any specific tag, which will use by default, as we did on the first Dockerfile presented. 14.21.2-buster latest I would recommend, at least, specifying the major node version that you are using, which would give us an image that we know it's mainly compatible with our local environment, but also will be using the most up-to-date official image, reducing the vulnerabilities and bugs that are constantly being found. So far we could change the first steps of our Dockerfile: FROM node:18 as build       # Naming our image to be use in later steps

WORKDIR /usr/src/app
COPY package.json .
COPY package-lock.json .
RUN npm install
COPY . .
RUN npx prisma generate
RUN npm run build In the next step, to reduce our final image size, we would like to use a reduced base image like or (Although has a smaller size, it's not built with , and some tools might not work as expected, watch out). What can happen ( and does in our case using Prisma) is that this smaller doesn't contain some libraries or tools needed from our app. In this case, we need to add . slim alpine alpine libc slim libssl-dev We should also set de variable to , so that different modules work accordingly, reducing the load of debug symbols and logs. NODE_ENV production FROM node:18-slim                                                                           # Base smaller node image
RUN apt update && apt install libssl-dev -y --no-install-recommends                         # Add missing dependency needed for prisma
WORKDIR /usr/src/app
COPY --from=build /usr/src/app/dist ./dist                                                  # Copy de dist folder generated in the previous step
COPY --from=build /usr/src/app/.env .env                                                    # Copy env variables to use
COPY --from=build /usr/src/app/package.json .
COPY --from=build /usr/src/app/package-lock.json .
RUN npm install --omit=dev                                                                  # Install without  dev dependencies to save some space
COPY --from=build /usr/src/app/node_modules/.prisma/client  ./node_modules/.prisma/client   # Copy generated prisma client from previous step
ENV NODE_ENV production
EXPOSE 3000
CMD ["npm", "run","start:prod"] With these two steps, we are going to save around 300 mb only for the different base images. Quick note, in older versions, use npm npm install --production 4 Better App Start There are some caveats running directly our app through . First, npm doesn't forward any signal to the spawned process, and our process would be assigned PID 1 which is treated differently by the kernel of our docker image. This can affect the ability to gracefully shut down our app and, cause difficult-to-debug problems. npm See the references at the end for more info. So, let's change our command with: RUN CMD ["dumb-init", "node", "dist/src/main"] 5 Security We should never want to run our application with the root privileges, and although the current images of node run with a low privilege user by default, all the files that we copied are owned by root. node In some cloud environments like AWS or Azure, this could have little to null consequences, it's better not to risk it. So, in every copy, we would downgrade to the same user. We could then add the argument to all our commands. node --chown=node:node COPY Putting it all together we get the that we introduced at the beginning: Dockerfile FROM node:18 as build
WORKDIR /usr/src/app
COPY package.json .
COPY package-lock.json .
RUN npm install
COPY . .
RUN npx prisma generate
RUN npm run build

FROM node:18-slim
RUN apt update && apt install libssl-dev dumb-init -y --no-install-recommends
WORKDIR /usr/src/app
COPY --chown=node:node --from=build /usr/src/app/dist ./dist
COPY --chown=node:node --from=build /usr/src/app/.env .env
COPY --chown=node:node --from=build /usr/src/app/package.json .
COPY --chown=node:node --from=build /usr/src/app/package-lock.json .
RUN npm install --omit=dev
COPY --chown=node:node --from=build /usr/src/app/node_modules/.prisma/client  ./node_modules/.prisma/client

ENV NODE_ENV production
EXPOSE 3000
CMD ["dumb-init", "node", "dist/src/main"] If you want to go more in-depth I recommend you the following articles: Snyk: 10 best practices to containerize Node.js web applications with Docker Docker: Best practices for writing Dockerfiles Sysdig: Top 20 Dockerfile best practices Yelp: Introducing dumb-init, an init system for Docker containers

5 Steps for Dockerizing NestJs With Prisma

It’s been almost a decade since Docker and containers changed the landscape of modern software delivery. Early in their evolution, there was around container security because they didn’t have a lot of the familiar architectural security elements when compared to VMs. Today, mature tooling and processes along with a widespread understanding of the risks and mitigation have persuaded many holdouts to adopt containers as another tool in their infrastructure strategies. a lot of fear This blog takes an updated look at the most mature and popular tools in the various stages of the container hardening process, giving you 7 strategies and related tools to try as you head into 2023. The strategies covered are: Container Image Creation Minimal Containers Container Image Scanning Policy Enforcement Container Encryption Container Signing Host Operating System Vulnerability Scanning 1.  Container Image Creation Container creation requires an understanding of the software packages, users, and environment settings that are necessary to deploy a workload. Container builds use a manifest of instructions for building containers, which are read and executed sequentially to generate a new container. A variety of tools can produce containers: Dockerfile Buildah Packer Packer is a favorite of mine and I’ll use it as an example. It builds containers using the . An advantage of using Packer is having a common workflow for building operating system as well as containers. Packer also has a " " capability. The post-processor creates a framework for container tagging, encrypting, signing, and container scanning. Packer can then push to artifact repositories after the build and post-processing steps. Docker builder plugin golden images post-processor Once the build step is complete, a container is pushed to an approved repository. To push to approved repositories, users should have an authentication and authorization step to grant access to a container repository. The credentials for accessing container repositories can then be stored in a . secrets manager 2. Minimal Containers A security benefit of using containers is having a limited number of operating system packages inside a container. Containers with a precise set of software packages decrease the number of possible security vulnerabilities in a container. In the last few years, there has been an increase in the number of minimal Linux distributions for containerization, and you may want to consider adopting some of them if you’re looking for more ways to improve your container security posture. A few of the container images that use very minimal operating systems with just enough packages installed to run include: Alpine Ubuntu Minimal Chainguard’s Wolfi Another way to limit the size of containers and the number of unnecessary software packages is to do . A container that serves a Golang REST API would have two stages in the multi-stage build: multi-stage builds The primary stage would be labeled as the compile stage. The compile stage needs an operating environment with enough packages to build the Go binary. The second stage would use a minimal base operating system and the Go binary created in the compile stage. Minimal containers, whether they’re ready out of the box or homegrown via multi-stage builds, minimize your threat surface because there are fewer packages and operating system components to exploit. 3. Container Image Scanning Scanning container images is a critical security step in the container lifecycle. You can run and enforce image scans at different stages of the software delivery lifecycle. Scans can execute… Before an image is pushed to a repository In the image repository Before running in an orchestration environment like Kubernetes There are many popular scanning tools to choose from. Some of the popular options include: Prisma Cloud Snyk (GitLab's ) Trivy default container scanner Grype If you want to scan a container before an image is pushed to a repository, an image build tool like Packer can do this during the build process, scanning images and checking for container vulnerabilities. If you want to scan a container when it’s in the image repository, tools like and are able to scan a container repository and monitor security drift as containers become stale and new common vulnerability and exposure reports are released on containers. Sysdig Jfrog Scanning tools can also continuously monitor web feeds for new vulnerabilities and send alerts when an image is out of compliance. At the enterprise level, there are tools that go even further and automate base-image upgrades when they find vulnerabilities. , the most commonly used infrastructure as a code provisioning tool can integrate with container scanning tools to ensure that images have been scanned before being deployed onto specific architecture. And if your company runs the commercial versions of Terraform, they can use native or third-party tools and guardrails to automatically scan and enforce rules on container images before running in an orchestration environment  (e.g. Kubernetes, Docker Swarm, and Nomad). Terraform 4. Policy Enforcement Policy checks are a great way to enforce security standards on a system as part of the software delivery lifecycle.  In order to add a check before allowing a service to be run in Kubernetes, secure environments require additional gate checks called . admission controllers The admission controller can scan containers for vulnerabilities and check for compliance at runtime. These gate checks should be codified with (PaC). Just like infrastructure as code, policies can be tracked, version controlled, and reused like modules or functions in programming languages. Example policies could include: policy as code Validation of container signatures for Software Bill of Materials Enforcing approved container registry whitelists Container scan severity thresholds - (Prohibit the deployment of services that have high severity CVEs in packages) Enforce the use of necessary tags or labels on services Ensuring container applications are not running as the root user Look for a policy as code or other guardrail features in the tools you use. For example, if you want to run checks and enforce them on containers before they’re deployed to an orchestrator,  use a native feature like admission controllers in Kubernetes or Sentinel policy as code in Nomad (enterprise version). Terraform can also use Sentinel (enterprise version) to enforce policy before deploying a container onto a single instance server. 5. Container Encryption Encryption is an additional security measure with an authentication and authorization step before the manipulation of a container. When using encryption tools for containers, the container itself is encrypted to include all the internal files and the metadata associated with the container. This encryption happens at the build step before being pushed to an external repository. Typical key encryption formats are: JWE (RFC7516), PGP (RFC4880), and PKCS7. The encryption key can be stored in a secrets manager. is getting the but there are other options here as well: Vault broadest adoption Azure Key Vault AWS Secrets Manager GCP Secrets Management These secret managers can also add an authentication step to encrypt and decrypt containers. CI/CD platforms, container scanning tools, and other services also need access to the encryption key stored in the secrets manager, so make sure it has a broad integration ecosystem. Vault, for example, integrates with open-source and commercial tools to add an encryption and decryption step into the software delivery lifecycle. (a tool for moving encrypted image repositories), (for building and running encrypted containers), and Containerd's (to encrypt and decrypt Open Container Initiative (OCI) containers) are examples of tools that can add a cryptographic workflow in your container image pipeline. Skopeo Singularity Imgcrypt When importing containers from outside sources, it’s important to have tools that can encrypt them and keep them up to date with vulnerability patches. Running container scans and encrypting containers before they are pushed to trusted sources are two great ways to continuously secure your software supply chain and image repository. To run a container in an orchestration pipeline, the service needs to authenticate and be authorized to access the decryption key. This additional step in the pipeline adds file encryption and provides least-privilege access to the container at runtime. 6. Container Signing is critical for defending customer data, especially with the industry’s ubiquitous use of open-source software. Many organizations like SLSA and OpenSSF’s governing boards have created frameworks for measuring the security and integrity of the software supply chain. Containers can have digital signatures applied to commits as metadata with tools like . Securing the software supply chain Sigstore's cosign Additional metadata like the author of the commit or vulnerability scan results can be used as a validation gate check before deploying to a container orchestration platform. The commit signature can use a self-signed key with cosign to verify the authenticity of the steps or allow integrations with external public key infrastructure (PKI) servers. In PKI workflows, Vault can act as a certificate authority and generate programmatically. PKI certificates The benefit of using Vault certificates for signing a commit is the authentication process. Authenticating before each commit affirms that the human or machine executing the signing process is authorized to sign container images. Dynamic, short-lived PKI certificates shorten the threat window in which an adversary might gain access to a key and use it to inject bad code or improperly sign a container. Tools like add a timestamp of the signature verification to an immutable ledger. This ledger can be used to validate the signature authenticity even after the short-lived certificate has expired. Sigstore's Rekor 7. Host Operating System Vulnerability Scanning Vulnerabilities in the host operating system provide threat vectors to the containers running on the host system. Hence, the host operating system running the container needs to be monitored and scanned for vulnerabilities.  OS scanning tools have been around for ages but some of the popular commercial and open-source host vulnerability scanners are: Palo Alto’s Prisma Cloud Snyk OpenSCAP OpenVaS NMAP It’s good security hygiene to keep operating systems up to date and secure but it can be a pain to manually update hosts consistently. One way to speed this up is to automate the process and treat your host systems like cattle vs. pets. Container orchestration platforms allow the host operating system to become commoditized and much easier to cull. If configured correctly, host operating systems can be shut down and containers will ultimately find a new home on an available server in the cluster with the appropriate amount of CPU, memory, and disk. As operating systems are scanned and CVEs are released, automated triggers from scanning tools can , like Packer (image builder) and Terraform (infra provisioning), to quickly patch an entire cluster of servers with no downtime for running services. Finding a workflow to get patching quickly will ensure there aren’t any underlying attack vectors allowing access to the container from the underlying operating system. kick off a toolchain Final Notes Container security is a must in modern cloud architecture. Hopefully, this list of current tools will help improve your process for securing the creation, signing, encrypting, verifying, validating, provisioning, connecting, and running of containers. More strategies? Did I miss anything?  Let me know in the comments! For more information, check out the following resources: NIST Container deployments NIST Application Container Security Guide

Container Security Tools to Try in 2023

(This article is a collection of best practices and tips regarding securing containerized environments. And there is a previously published article about the K8S hardening.) https://hackernoon.com/how-to-harden-k8s-based-on-the-recent-updated-nsas-kubernetes-hardening-guide And Understanding How Containers Present Unique Security Challenges We all know that running cloud-based containers includes the flexibility of spinning applications up and down for users — or what we call “ ” and better integration with DevOps. They also provide cost-saving infrastructure compared with monolithic applications running on servers or virtual machines. WORA (write once, run everywhere) Different companies, big or small, are looking into how to run their business applications with this technology. As a result, the adoption of containerized applications is at an all-time high. According to the survey from the : Cloud Native Computing Foundation (CNCF) Kubernetes adoption among the ever-expanding cloud-native community is approaching 100%, meaning those investing in cloud-native are strongly bought in and excited for the future. The Container’s Threat Landscape When we look into the 243,469 K8S clusters are Kubernetes clusters also exposed port 10250, used by the kubelet as a default setting. As a result, recent data revealed by Shodan, publicly exposed. Furthermore, these attackers could scan the internet and find those clusters with minimum effort. Once the cluster is found, attackers could use the kubelet API as an entry point in targeting Kubernetes clusters to More impactful actions are possible, such as lateral movement to other internal resources, privilege escalation, and finally, jumping into the jewel💎 — the confidential data. mine for cryptocurrency. With more and more data in containers, so does the interest in cyberattacks targeting such applications. According to VMware’s “ 2022”, State of Kubernetes survey 97% of organizations have concerns about Kubernetes security. Redhat also provides similar data with their “ ”, saying that in their Kubernetes and container environments during the last 12 months. 2022 state of Kubernetes security report 94% of the respondents have experienced a security incident Akamai’s security researcher Larry Cashdollar launched an by setting up a standalone Docker as honeypot Dock to see how frequent and what kind of attacks would be recorded. The result is scary. He specifically configured the honeypot simply to look like a vulnerable cloud instance. exciting but alarming experiment In only 24 hours, the honeypot was leveraged by FOUR different cybercriminal campaigns! Containers and Kubernetes attacks are common, and organizations have difficulties protecting themselves. Meanwhile, the businesses are transforming, and even though there are security concerns, they are putting more and more data into them. 3 Main Security Concerns in Containers Although different, a container can still be compromised in many ways, just like traditional infrastructure. Therefore, I will highlight the most common container risk factor here. 1# Misconfiguration Based on the prediction of from their analysis, by 2025, 99% of cloud security failures will be the mistakes of customers. As you can imagine, containers are often deployed in very dynamic environments. Therefore, any misconfiguration, no matter access, networking, or other related settings, can lead to a stealthy security hole for users but not to cybercriminals. Gartner which are far less secure than customized, hardened settings. Attackers can find a problem in the default settings faster than understanding a new one. Smaller companies are generally using default configurations than large organizations. Basic misconfiguration accepts the default settings in the production environment, Such small mistakes can lead to expensive problems. When we look back into Sep 2021, published by the is the first known windows container malware and heavily obfuscated malware targeting K8S. According to the same research team, the primary purpose of Siloscape is to open a backdoor from poorly configured K8S clusters. As a result, the malware can further run malicious containers. Palo Alto Networks, Siloscape malware 2# Vulnerable Container Images Container images are static files with executable code that can be used to create a new container on a computing platform. Images are available via open-source repositories that are widely accessible online for easy download and deployment. What if someone uploads the pre-installed malware into images and plants it into the public repository? When someone deployed those images, the malware would be running on day-0 without any action from the attackers. It’s a specific type of supply chain attack. In 2020, a bug was found ( ) in the Containerd runtime software for complete container lifecycle management. By the time they obtain the token, they can disguise themselves as the author and take hostage of a cloud project. CVE-2020–15157 Adversaries could exploit it by creating specially-crafted container images to steal the host’s token, which they were pulled into a project. Another example of how attackers leverage malicious container images is illustrated by Team Nautilus, a threat research team from . They found Aqua Security five container images on Docker Hub used for mining cryptocurrency and as part of a supply chain attack specifically targeting cloud-native environments. 3# Zero-Day Vulnerabilities (+ Known CVEs) Perhaps zero-day vulnerabilities are a big problem for all software — and containers are no exception. Although cloud providers invest heavily in securing their platforms, it’s unavoidable that zero-day vulnerability can exist and put customers at risk. The most alarming example of this category is ,” found by Palo Alto Networks. Similar to Siloscape, Azurescpe is the first known vulnerability that could allow a user of a public cloud service to “escape” the environment (Microsoft Azure). “Azurescape This container escape is just an example of what known or zero-day vulnerabilities can impact a container environment. One public-facing hole could lead to a chain of exploits. When combined with a few misconfigurations, it would become a container takeover or even infiltrate other customers’ instances. about cloud-native and security usage found that report also stressed that some respondents stated they are prepared to take these risks to move faster and release applications quicker. A report in February by Sysdig 75% of containers contain high severity vulnerabilities. However, the Best Practices for Container Security Containerized environments can introduce distinctive challenges for visibility and application of security controls, but following a layered-security approach can significantly reduce the attack surface. The traditional approach of having a list of ‘bad’ things to look for won’t work in a container-based environment. Given the scalability and agility of these environments, organizations must be able to analyze the operational data in real-time and look for abnormal behaviors in runtime. 0# Continuous Improvement The first thing for container security is implementing security practices in the CI/CD pipeline and the entire build, store and deploy process of container images that include: Static Application Security Testing (SAST); Securely storing the container images, Vulnerability scanning for container images and; Enforce image content trust. Defense-in-Depth (DiD) in Containers The container security best practices don’t just include the delivered applications and then securing the container’s image itself, but the entire stack for building, distributing and executing the container. A layered approach should be followed. For starters, this includes: Cloud platform configuration The computing host (physical or virtual) The Operating System K8S cluster The container runtime Namespace The application code Each layer would have its own security controls. For example, keeping the cluster infrastructure up to date is always important. But for the purpose of this guide, I would skip the part that is outside the K8S cluster. 1# Role-Based Access Control (RBAC) RBAC is the frontline of defense in Kubernetes. It lets the user control who can access the API and their permissions. Official Kubernetes document provides detailed descriptions for . Although RBAC is enabled by default, simply having RBAC enabled is not sufficient. Authorization policies should be handled carefully and properly applied. Role-based Access Control (RBAC) Tips: Always use RBAC with the least privilege principle. As a baseline, we need to make sure That means using the RBAC policy to limit users and groups to only the actions and tasks they need. Also, confirm that the Kubernetes service and other user accounts have minimal privileges granted. not to give cluster-wide permissions and not give anyone cluster-admin privileges unless necessary. 2# Benchmarking and Remediation As stated above, Thus, to spot those misconfigurations, we need something to compare with. The Center for Internet Security (CIS) is the de-facto standard among various sources of best practices, benchmarks, and hardening guides, misconfiguration is the primary source of container-related attacks. the is the de-facto standard. Center for Internet Security (CIS) https://www.cisecurity.org/benchmark/kubernetes Whether it is a physical server where the Linux is installed as a platform for containers, a virtual machine provisioned on a cloud service provider, or an on-prem box, it may contain insecure out-of-the-box settings that no one knows. After all, we cannot assume that a cluster provisioned by a cloud provider is perfectly secured. Apart from K8S benchmarking, which is the most complex for cybersecurity professionals to review, CIS also provides similar checking for physical servers, especially Linux. and one specifically for Debian, Centos, Red Hat, and many other distributions. CIS has a benchmark for Distribution Independent Linux https://www.cisecurity.org/benchmark/distribution_independent_linux/ 3# Cloud Security Posture Management Benchmarking can be extended to cloud provider accounts, too. Developers may not have access to those settings, but it is equally crucial for the overall security of a containerized environment. It is different from the other settings as this part belongs to the management plane. A separate security control defined by Gartner for this area is called Initially, CSPM supported you in discovering and visualizing the IaaS and PaaS asset inventory. But it may be extended to help you save time and minimize risk across your entire cloud/container security stack. According to , CSPM should include the capabilities of: . “Cloud Security Posture Management” (CSPM) Gartner Continuous visualization of configurations Assets discovery, classification, and risk assessment Standard misconfiguration remediation and logging Compliance reports with security frameworks (e.g., PCI DSS, HIPAA, SOC 2…) 4# IaC Scanning IaC stands for Infrastructure-as-code, which refers to the technology and processes used to manage and provision infrastructure using code. Although IaC is not directly related to containers, it usually comes with DevOps. IaC simplifies DevOps processes such as peer reviews, version control, automation, and CI/CD delivery. IaC comprises resource declarations, input and output variables, configurations, and parameters. IaC is usually JSON, YAML, or HCL based, and a single file can contain all resources and configurations required to spin up a whole infrastructure, including: compute, storage, networking, identity access management, security, and more. Apart from its operational efficiencies, IaC can be employed to automate security processes and integrate them with DevOps as part of the transition to DevSecOps. However, IaC is a two-way sword. By provisioning cloud resources across environments with a unified, standard language, developers and operations can better readily remain on the same page and work together to secure cloud-native applications. However, it also creates hidden traps inside the code without review. IaC scanning software can parse standard cloud-native format templates. Then, they can set controls based on security best practices, providing developers or administrators with the knowledge of where they should apply further hardening to improve the security of the declared IaC environments. These tools can separate security problems such as: a Docker image initiated to run as the root user, a Kubernetes manifest that requests a node’s privileged access to the file system, or an Ansible/ Terraform script that configures an open access S3 bucket. As a result, adding security checks to IaC can isolate security vulnerabilities into a dedicated build and release pipeline. Likewise, IaC security simplifies workflows by embedding them into developer workflows to support cloud insight in both build and runtime. Final Words Although cloud-native technologies and containers are still a novice, the core security challenge remains; Organizations must consider how to accelerate development while retaining robust security controls, no matter it is a monolithic application or a containerized environment. These two objectives are still competing for equal attention in the container space. Although having containers in the picture fostered scalability and agility, they also increased the overall complexity. Securing containers needs a comprehensive approach. First, we must ensure that we address all teams’ needs within your organization. Next, make sure we can automate the procedure to fit the DevSecOps processes and that we also can meet deadlines and launch applications fast while protecting all of them. Security can no longer be an enforcer at the last minute with demands to change your workflow. Instead, it needs to build trusted security controls and automated processes from the start to address security concerns and make it easier to bridge the gap between each team. Thank you for reading. May InfoSec be with you🖖.

Incomplete Guide for Securing Containerized Environment

There are lots of videos and tutorials about how to get started with Kubernetes scattered about online, but what about resources that set you up with your own real Kubernetes environment? I've compiled a list of three resources where you can get started with Kubernetes and Red Hat OpenShift, Red Hat's enterprise Kubernetes platform. No payment is required. 1. OpenShift Open Labs Want to dive deep into Kubernetes and Red Hat OpenShift? Open Labs gives you six guided walkthroughs to explore scenarios in your own Red Hat OpenShift cluster. These include: Building hybrid cloud apps by connecting to a Cloudant service using OpenShift operators Logging with LogDNA Cloud monitoring with SysDig Securing microservices . ℹ️ Tip: In order to save resources, you'll have access to the cluster for , after which you can request another cluster one hour ℹ️ Tip: There are also Kubernetes-only versions of some labs available . here 🔗 Link: https://developer.ibm.com/openlabs/openshift 🧑‍🎓 Good For: Learning about OpenShift and Cloud services, logging and SysDig Installing and configuring OpenShift Operators 🤔 Be Aware: Clusters time out after one hour 2. Earn your Build Smart on Kubernetes Badge If you only have a couple of hours to spare and want to learn about deploying applications to Kubernetes and Red Hat OpenShift, this program will get you there. You'll learn how to: Deploy a node.js application using source-to-image, Deploy a Java microservice application on Open Liberty, Deploy a machine learning model and use it to classify images At the end of the workshop, you'll receive a badge certifying completion that you can share on social media (if you're into that kind of thing!) ℹ️ Tip: If you're going for the badge, make sure you open the quiz before starting the workshops! The quiz asks for the output of a command from each lab. So it's easier to complete the quiz as you run through labs. . ℹ️ Tip: The badges are issued once per week, so you may have to wait up to seven days after completion until your badge is issued 🔗 https://www.credly.com/org/ibm/badge/build-smart-on-kubernetes/ 🧑‍🎓 Good For: Application developers interested in deploying apps to k8s Sharing your achievement on social media 🤔 Be Aware: Complete the quiz as you do the labs You may wait a week for the badge 3. Try.OpenShift.com Red Hat’s Developer Sandbox contains a number of workshops that give you a deep knowledge of Kubernetes and Red Hat OpenShift, including: Learn Kubernetes using Red Hat Developer Sandbox ℹ️ Tip: Red Hat’s Developer Sandbox comes pre-configured with CodeReady Workspaces, Red Hat's productized version of . Eclipse Che 🔗 Link: https://try.openshift.com 🧑‍🎓 Good For: Learning through kubectl and git on your local machine Working with , React, and MariaDB quay.io Deploying applications working with Kafka and JavaScript 🤔 Be Aware: Some of these labs have detailed command line requirements -- but this can be an opportunity for education! Resources Free links from the Linux Foundation Kubernetes Training Keep up to date with the Kubernetes.io blog David's Twitter

3 Free Ways to Learn Kubernetes and Red Hat OpenShift

The Containerized Software Development Guide

Let’s talk about Kubernetes security As Kubernetes continues to grow in adoption, it is important for us to know how to secure it. In a dynamic infrastructure platform such as Kubernetes, detecting and addressing threats is important but also challenging at the same time. Falco, the open source cloud native runtime security project, is one of the leading open source Kubernetes threat detection engines. Falco was created by Sysdig in 2016 and is the first runtime security project to join CNCF as an incubation-level project. Falco detects unexpected application behaviour and alerts on threats at runtime. Why is it difficult? Security is one of the harder challenges of running Kubernetes according to . The reason it is difficult is that there are multiple moving layers in a cloud native stack, hence operators may not focus on security early on. Another contributor is that some distributions of Kubernetes may not be secure by default, contrary to what operators assume. this analysis Prevention and Detection Information security is a process that moves through phases building and strengthening itself along the way. Security is a journey, not a destination. Although the Information Security process has multiple strategies and activities, we can group them all into three distinct phases - prevention, detection, and response. Preventive measures Preventive measures include having proper access control, authentication and authorization in place. No matter what level of protection a system may have, it will get compromised given a greater level of motivation and skill. There is no foolproof “silver bullet” security solution. A defense in-depth strategy should be deployed so when each layer fails, it fails safely to a known state and sounds an alarm. The most important element of this strategy is timely detection and notification of a compromise. Detective measures An example of detective measures includes sending logs from security and network devices like host-based intrusion detection systems (HIDS) and network intrusion detection systems (NIDS) to an SIEM and building rules to alert when suspicious activity is seen. According to the defense in-depth approach, we should be auditing and placing detection triggers on multiple layers of the technology stack, from looking at cloud audit logs (like Cloudtrail), the Kubernetes cluster, containers, application code, host OS and the kernel. We will take a look at the detective measures in this blog which will further help us to respond to these threats. Image credit: @leodido Setting Falco up on Kubernetes The most secure way to run Falco is to install Falco directly on the host system so that Falco is isolated from Kubernetes in the case of compromise. Then the Falco alerts can be consumed via read-only agents running in Kubernetes. Falco can also be run directly in Kubernetes if isolation is not a concern. We will be setting Falco up using Helm in this tutorial, but you should be aware of the pros and cons of the method you are choosing. Prerequisite: We need a working Kubernetes setup for this. You can use a cloud Kubernetes offering from AWS/GCP or set one up yourself locally using . We also require kubectl and to be installed on your client machine. Steps minikube Helm Let’s start with the installation of Falco. 1. Add the falcosecurity repo in Helm $ helm repo add falcosecurity https: $ helm repo update
Hang tight we grab the latest your chart repositories...
...Successfully got an update the chart repository
...Successfully got an update the chart repository
Update Complete. ⎈Happy Helming!⎈ //falcosecurity.github.io/charts while from from "falcosecurity" from "stable" 2. Installing the chart $ helm install falco falcosecurity/falco
NAME: falco
LAST DEPLOYED: Mon Nov : : NAMESPACE: STATUS: deployed
REVISION: TEST SUITE: None
NOTES:
Falco agents are spinning up on each node your cluster. After a few
seconds, they are going to start monitoring your containers looking security issues.
No further action should be required. 9 22 09 28 2020 default 1 in for 3. After a few seconds Falco should be running, to verify, you will see the pods you created in a moment. $ helm ls
$ kubectl get pods Setting up the environment We will need an environment to emulate the attacks and detect them. Let us set it up. We will be using Helm for this. Let’s add Helm’s stable repository and install chart from it. mysql-db $ helm repo add stable https: $ helm repo update
Hang tight we grab the latest your chart repositories...
...Successfully got an update the chart repository
...Successfully got an update the chart repository
Update Complete. ⎈Happy Helming!⎈ //charts.helm.sh/stable while from from "falcosecurity" from "stable" $ helm install mysql-db stable/mysql
NAME: mysql-db
LAST DEPLOYED: Mon Nov : : NAMESPACE: STATUS: deployed
REVISION: NOTES:
MySQL can be accessed via port on the following DNS name within your cluster:
mysql-db.default.svc.cluster.local
... 9 22 11 07 2020 default 1 3306 from Let us now monitor Falco logs: $ kubectl get pods
NAME                      READY  STATUS   RESTARTS  AGE
falco rr9r / Running m
mysql-db-d5dc6b85d hrm / Running m
ubuntu / Running m

$ kubectl logs -f falco rr9r # Replace your Falco pod name here -6 1 1 0 49 -77 1 1 0 47 1 1 0 43 -6 with Analyzing Falco’s logs The first steps when an attacker does after they gain access to a Kubernetes cluster is to enumerate available network hosts. An attacker will try to find their way around a seemingly new environment. They can try to use safe/less noisy commands to gain more insights from the cluster. Let us go through the steps an attacker might do and look at the corresponding detection signals from Falco. We will use the default ruleset which comes with Falco, these rules can be tuned as per your needs in your environment. You can find Falco’s default rules here: https://github.com/falcosecurity/falco/tree/master/rules Terminal shell in container Description: Detecting terminal shells being spawned in pods. We open a terminal shell on a running pod to replicate the scenario. $ kubectl exec -it mysql-db-d5dc6b85d hrm -- bash -il # Replace the mysql pod name you have -77 with Detection: : : : Notice A shell was spawned a container an attached terminal (user=root user_loginuid= k8s.ns= k8s.pod=mysql-db-d5dc6b85d hrm container= fc8155f9d1a shell=bash parent=runc cmdline=bash -il terminal= container_id= fc8155f9d1a image=mysql) k8s.ns= k8s.pod=mysql-db-d5dc6b85d hrm container= fc8155f9d1a 18 08 40.584075795 in with -1 default -77 3 34816 3 default -77 3 Contact Kubernetes API Server From Container Description: We run kube-recon, which is a tool which does initial reconnaissance in a Kubernetes environment. This rule detects attempts to contact the Kubernetes API Server from a container. $ kubectl run kuberecon --tty -i --image octarinesec/kube-recon
/ # ./kube-recon / / : : Testing K8S API permissions / / : : Your K8S API Server is configured properly / / : : Running Nmap on the discovered IPs / / : : Getting local ip address and subnet / / : : Trying to download EICAR file / / : : Downloaded EICAR successfully. No malware protection is place 2020 11 09 18 21 22 2020 11 09 18 21 23 2020 11 09 18 21 23 2020 11 09 18 21 23 2020 11 09 18 21 23 2020 11 09 18 21 23 in Detection: : : : Notice A shell was spawned a container an attached terminal (user=root user_loginuid= k8s.ns= <NA> container=4f63870599d0 shell=sh parent=<NA> cmdline=sh terminal=34816 container_id=4f63870599d0 image=octarinesec/kube-recon) k8s.ns=<NA> k8s.pod=<NA> container=4f63870599d0
18:21:22.657590195: Warning Docker or kubernetes client executed in container (user=root user_loginuid=-1 k8s.ns=default k8s.pod=kuberecon container=4f63870599d0 parent=kube-recon cmdline=kubectl get pods image=octarinesec/kube-recon:latest) k8s.ns=default k8s.pod=kuberecon container=4f63870599d0
18:21:22.723707794: Notice Unexpected connection to K8s API Server from container (command=kubectl get pods k8s.ns=default k8s.pod=kuberecon container=4f63870599d0 image=octarinesec/kube-recon:latest connection=172.17.0.5:56972->10.96.0.1:443) k8s.ns=default k8s.pod=kuberecon container=4f63870599d0 18 20 45.927730981 in with -1 k8s.pod= < > NA Checking if shell is a container environment (Change thread namespace) Description: amicontained is a tool to check whether the shell is a containerized environment. The rule detects an attempt to change a program/thread’s namespace. $ cd /tmp; curl -L -o amicontained https: Output: 
Container Runtime: docker
Has Namespaces:
  pid: user: AppArmor Profile: kernel
Capabilities:
  BOUNDING -> chown dac_override fowner fsetid kill setgid setuid setpcap net_bind_service net_raw sys_chroot mknod audit_write setfcap
Seccomp: disabled    
Blocked Syscalls ( ):
  MSGRCV SYSLOG SETSID VHANGUP PIVOT_ROOT ACCT SETTIMEOFDAY UMOUNT2 SWAPON SWAPOFF REBOOT SETHOSTNAME SETDOMAINNAME INIT_MODULE DELETE_MODULE LOOKUP_DCOOKIE KEXEC_LOAD OPEN_BY_HANDLE_AT FINIT_MODULE //github.com/genuinetools/amicontained/releases/download/v0.4.7/amicontained-linux-amd64; chmod 555 amicontained; ./amicontained true false 19 Detection: : : : Notice Namespace change (setns) by unexpected program (user=root user_loginuid= command=amicontained parent=bash k8s.ns= k8s.pod=kuberecon container=c6112967b4f2 container_id=c6112967b4f2 image=octarinesec/kube-recon:latest) k8s.ns= k8s.pod=kuberecon container=c6112967b4f2
Mon Nov : : : Falco internal: syscall event drop. system calls dropped last second. : : : Critical Falco internal: syscall event drop. system calls dropped last second. (ebpf_enabled= n_drops= n_drops_buffer= n_drops_bug= n_drops_pf= n_evts= ) 18 43 37.288344192 -1 default default 9 18 43 37 2020 9 in 18 43 37.970973376 9 in 0 9 0 0 9 15232 Next steps In this tutorial, we looked at the basics of Kubernetes security monitoring and how Falco allows us to use rules to achieve the detection of security issues. The default detection ruleset of Falco is enough to get yourself up and running, but you will most likely need to build on top of the default ruleset. We will explore building and tuning these rules in the upcoming posts on security. That’s a wrap folks! Do share your thoughts in the comment section below. Previously published at https://www.infracloud.io/blogs/introduction-kubernetes-security-falco/

Kubernetes Security 101: Cloud Native Runtime Security with Falco

There is an endless supply of blog posts, white papers, and slide decks, evangelizing the virtues of microservices. They talk about how microservices “increase agility,” are “more scalable,” and promise that when you make the switch, engineers will be pounding at your office door looking for a job. Let’s be clear, though occasionally exaggerated, the benefits of microservices can be real in some cases. Particularly for large organizations, with many teams, microservices can make a lot of sense. However, microservices aren’t magic -- for all of their benefits, they come with significant drawbacks. In this post, I’ll describe how the distributed nature of microservices makes them inherently more complex. Distributed Systems Are Hard A distributed system is any collection of computers that work together to perform a task. Microservices are simply a type of distributed system designed for delivering the backend of a web service. Since the early days of distributed systems research going back to the 70s. We’ve known that distributed systems are hard. From a theoretical perspective, the difficulty mostly arises from two key areas: consensus and partial failure. Consensus From a theoretical perspective, the fundamental issue with building workable distributed systems comes down to the problem of consensus – agreement on distributed state. Nearly all distributed systems research attempts to grapple with this problem in some way. Paxos, Raft, Vector Clocks, ACID, Eventual Consistency, Map Reduce, Spark, Spanner, and most other significant advances in this area all are fiddling with the tradeoff between strong consensus and performance in some way. To better understand the problem of distributed consensus, let’s illustrate with an example. Suppose Bob asks Server_1 to write x=5 while concurrently Jill asks Server_2 to write x=6, does x equal 5 or 6? Naively, one could look at the time x=5 occurred, and the time x=6 occurred, and choose whichever happened last. But how do you determine the the writes happened. time Look at a clock? Whose clock? How do you know that clock is accurate? How do you know, Bob, Jill, Server_1, and Server_2 agree with that clock? Clocks are notoriously out of sync, and (as Albert Einstein taught us), that's not fixable[1]. For that matter, does everyone really need to agree on the value of x? If so, how much agreement? How long should the agreement take? What if Bob dies while trying to reach agreement? It gets complicated. So, given that distributed consensus is hard, how does this problem manifest in the context of microservices? Good microservice implementations tend to sidestep the issue altogether by simply disallowing shared state. In the case of our above example, there exists no x such that two microservices need to agree on the value of x at any particular point in time. Instead, all shared state in the system is punted to an external database or the container orchestrator. This approach both does and doesn’t solve the consensus problem. It doesn’t solve the problem in the sense that, from a theoretical perspective, there still is shared state that still requires management. You’ve just moved it. By the way, this is why Kubernetes and databases are so darn complicated. The approach does solve the problem in that, from a practical perspective, Kubernetes and databases are better at managing shared state than most microservices. Those systems are designed by engineers who spend all day every day thinking about these issues. As a result, they’re more likely to get consensus right. Partial Failure Consider an HTTP request serviced by a monolith. When the request is received, a single server handles the transaction from beginning to end. If there is a problem, be it a software bug or hardware failure, the entire monolith crashes – every failure is a total failure. Now consider the same HTTP request coming into a microservice. That microservice may send new requests to other microservices who, in turn, may generate more requests going to yet more microservices. Now suppose one of those microservices fails. What now? One or more microservices are depending on the data microservice was preparing. that What should they do? Wait for a while? How long? Try again? Try someone else? Who else? Give up and do their best with the data they’ve got? Microservices must be engineered to handles these issues, again making them more challenging to develop. Partial failure has been described as an unqualified good thing. The thinking goes, by supporting partial failure, an application becomes more resilient – small problems can be papered over gracefully. In my opinion, the benefits are small, rarely obtained in practice, and come at the expense of vastly increased implementation complexity. More Moving Pieces In addition to the theoretical challenges of microservices, there’s also just a lot of them. Having so many moving pieces complicates nearly every part of the stack and every part of the software development lifecycle. Development You can typically run a monolith directly on your laptop. Getting microservices to work on a local machine requires more specialized tools such as docker-compose and minikube. Furthermore, they’re CPU and memory intensive, making them painfully slow on a laptop. Note, check out Kelda , and specifically our whitepaper for a detailed description of this problem. Debugging Everything happening in a monolith occurs in a single process. You can attach the debugger of your choice, and you are off to the races. With microservices, a single request may be spread across dozens of different processes. Distributed tracing tools like Jaeger may help, but it’s still a challenge. Logging With a monolith, you can store logs in a file and grab them when needed. With microservices, you need a tool like Splunk or the ELK stack to handle this for you. Monitoring Simple on-server monitoring tools like Nagios don’t scale when you’ve got hundreds of microservices. Again, better tools (Prometheus/Datadog/Sysdig, etc.) make the problem tractable, but it’s still hard. Deployment Tools like Chef and Puppet are good enough for deploying a monolith, but for microservices, you need something much more sophisticated like Kubernetes. Networking Monoliths can be handled with a simple load balancer. Microservices have many more endpoints, all of which require load balancing, service discovery, consistent security policy, etc. I suppose service mesh can help with this (I’m not convinced, but that’s a topic for a future post). Microservices Make Sense, Sometimes From a technical perspective, microservices are strictly more difficult than monoliths. However, from a human perspective, microservices can have an impact on the efficiency of a large organization. They allow different teams within a large company to deploy software independently. This means that teams can move quickly without waiting for the slowest common denominator to get their code QA’d and ready for release. It also means that there’s less coordination overhead between engineers/teams/divisions within a large software engineering organization. And while microservices can make sense, the key point here is that they aren’t magic. Like nearly everything in computer science, there are tradeoffs — in this case, between technical complexity for organizational efficiency. A reasonable choice, but you better be sure you need that organizational efficiency, for the technical challenges to be worth it. [1]: Yes, of course, most clocks on earth aren’t moving anywhere near the speed of light. Furthermore, several modern distributed systems (notably Spanner), rely on this fact by using extremely accurate atomic clocks to sidestep the consensus issue. Still, these systems are, themselves, extremely complicated, proving my point: distributed consensus is hard. Kelda makes microservices easier for developers on Kubernetes. Join our Slack community! Previously published at https://kelda.io/blog/the-dark-side-of-microservices/

The Dark Side of Microservices, Explained

Containerisation is growing and evolving rapidly, and when it comes to container orchestration, the two names that come to mind are Kubernetes and Docker Swarm. Both Kubernetes and Docker Swarm are open-source technologies that offer container orchestration. Although both the systems are not rivals, Kubernetes vs. Docker has been a long-debated battle. So, let’s do a deep dive into these applications. Kubernetes Kubernetes is an open-source application that provides automation, deployment, management, and scaling of a containerized application. It is widely used for massive-scale productions and for running heavy workloads. Docker Swarm Docker Swarm is the orchestration of Docker’s container. Docker swarm uses the Docker API, which makes it is easy to use and less complicated. It features a zero single-point-of-failure architecture, with automatically generated certificates and backward compatibility. Kubernetes vs Docker Swarm Kubernetes and Docker Swarm, both are orchestration tools that offer similar functionality. However, there are some basic differences between the operation and functionality of two systems, as discussed below. Installation and Set-Up The installation process in Kubernetes is manual and requires expertise and planning to make it ready to use. Moreover, different operating systems have different installation processes. If you want to use Kubernetes, you need to be acquainted with cluster configuration beforehand. On the other hand, Docker is simple to install and set up. For Docker, you need to learn one set of tools to configure and build an environment. Moreover, Docker Swarm provides flexibility with regards to nodes by allowing a new node to join a cluster as a worker or manager. Application Deployment In Kubernetes, you can develop an application using a combination of deployments, services, , or pods. micro-services On the other hand, google Kubernetes vs. docker swarm indicates that in Docker Swarm, you can deploy applications as services in a Swarm cluster. You can also use Docker Compose to deploy an app, and if you want to specify a multi-container, you can use the files. YAML Monitoring and Logging If the servers are deployed within the cluster, Kubernetes will support multiple monitoring and logging versions like Heapster/Grafana/ Influx, Elasticsearch/Kibana (ELK), and Sysdig. Talking about how Kubernetes is different from docker swarm, Docker Swarm supports monitoring only with third-party applications. Docker Swarm features an open API, which makes third-party integration easy. If you want to monitor using Docker Swarm, use Reimann. Working If you want to run Kubernetes, you need to know CLI (Command Line Interface). If you want to run Kubernetes on top of Docker, you will need to know as well. Docker CLI As far as Kubernetes vs. Docker is concerned, Docker Swarm is a tool of Docker, which requires the same language for navigation within the structure. This easy functionality makes Docker easier to use compared to Kubernetes. Scalability Scalability is a vital factor to consider while choosing the best container orchestration system. Kubernetes is an all-in-one framework, which makes it rather complicated to use. It offers a set of APIs and a robust cluster state, which reduces the process of deployment and scaling of the containers. Talking about google Kubernetes vs. docker swarm, Docker Swarm can deploy containers in comparatively faster, which promotes the reaction times to provide seamless on-demand scalability. Availability All the pods in Kubernetes are distributed among various nodes, which tolerate application failure and provide high availability. Kubernetes features load-balancing services that detect and remove unhealthy pods, which ensures high availability. Evaluating Kubernetes vs. Docker, Docker Swarm provides high availability as well; Swarm nodes can be utilised to replicate the services. Docker Swarm features swarm manager nodes that are responsible for managing the cluster and resources of worker nodes. Networking Kubernetes offers a flat network that allows all pods to communicate with each other. In Kubernetes, the model needs two CIDRs: one for IP address and the other one for services. Talking about how Kubernetes different from docker swarm, Docker Swarm features a node joining a cluster that creates a network of services for all the hosts in the Swarm. Docker Swarm users also have the option of encrypting container data traffic while creating their overlay network. Pros and Cons of Docker Swarm Let’s discuss the pros and cons of Docker Swarm to get a better idea of google Kubernetes vs. docker swarm. Pros Using a virtual environment usually takes a lot of time, but it is not the case with Docker Swarm. The documentation of Docker Swarm provides all the necessary information. The configuration process is fast and simple. Your application remains isolated in Docker. It also provides component reuse and version reuse. Cons Docker is a Linux-dependent platform and requires virtual machines to run on another OS. It does not have a storage option.The monitoring process in Docker is not advanced. Pros and Cons of Kubernetes To understand the Kubernetes vs. Docker difference, let’s talk about the pros and cons of Kubernetes. Pros In case of errors with multiple updates, you can roll back to the previous image. Kubernetes offers Horizontal Infrastructure Scaling, Auto-scaling, and Manual scaling, along with a Replication controller to ensure the cluster has an accurate number of pods in a running condition. Kubernetes monitors the health of containers and nodes and promotes the self-healing and auto-replacement of damaged nodes. Kubernetes allows the regular deployment of features without worrying about the downtime. In Kubernetes, data is divided across the containers, but if pods get damaged, the volume is removed automatically. Cons The installation process is tormenting, and if you are not using a cloud provider, it would be more challenging. It is hard to set up, and creating a new process takes a lot of time. If your application is stateless or clustered, you have to work on the application configurations. The Final Verdict First and foremost, you need to understand that Kubernetes vs. Docker is not a battle, as both systems provide a separate set of functionalities. Evaluating Kubernetes vs. docker, the difference is simple: Kubernetes is difficult and complicated to use but provides additional functionalities, whereas, Docker Swarm is easy to use and setup but offers a limited set of features. Therefore, if you are still confused about how is Kubernetes different from docker swarm, you can study google Kubernetes vs. docker swarm features to analyse which system suits your requirements. ( : ) Disclaimer The author works at GoodWorkLabs (Originally Published ) Here

Stories, News & Mentions about SYSDIG

Sysdig’s Stories on HackerNoon