Skip to content

Instantly share code, notes, and snippets.

@jwieringa
Last active November 15, 2019 07:09
Show Gist options
  • Star 5 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save jwieringa/9c8879d8c136979ef8e75a7aa05a3195 to your computer and use it in GitHub Desktop.
Save jwieringa/9c8879d8c136979ef8e75a7aa05a3195 to your computer and use it in GitHub Desktop.
Exploring running AWS Inspector on CoreOS Container Linux

AWS Inspector Support in a Containerized environment

Summary

  • If behavioral analysis is required, then the kernel module is required
  • The inspector agent cannot be compiled for container linux because the source code is not open
  • The inspector agent is dynamically linked and therefore must be run on a supported filesystem/OS
  • Therefore, the inspector agent must be run inside of a container
  • Once the inspector agent in the container needs to have the correct mounts and capabilites to scan the host systems

General Notes

  • Supported regions and operating systems

  • AWS Inspector Kernel module

    • Required to run Runtime Behavior Analysis rules package
    • Source is available via Tarball
    • The Kernel build targets specific distributions depending on their capabilities
  • AWS Inspector agent

    • Source is not made available so the agent must run in an image from a supported OS

Custom Kernel Module build

  • Download package
  • Verify signature
  • If on a non-supported OS, modify Makefile and build arguements

Example on CoreOS

$ modules=/opt/modules
$ mkdir -p "$modules" "$modules.wd"
# Create an overlay filesystem because /lib in read only
$ mount \
    -o "lowerdir=/lib/modules,upperdir=$modules,workdir=$modules.wd" \
    -t overlay overlay /lib/modules
$ . /usr/share/coreos/release
$ . /usr/share/coreos/update.conf
$ url="http://${GROUP:-stable}.release.core-os.net/$COREOS_RELEASE_BOARD/$COREOS_RELEASE_VERSION/coreos_developer_container.bin.bz2"
$ gpg2 --recv-keys 04127D0BFABEC8871FFB2CCE50E0885593D2DCB4
$ curl --fail --location "$url" |
    tee >(bzip2 --decompress > coreos_developer_container.bin) |
    gpg2 --verify <(curl --location --silent "$url.sig") -
$ systemd-nspawn \
    --bind=/lib/modules \
    --image=coreos_developer_container.bin
$ . /usr/share/coreos/release
# Check out the current CoreOS version's ebuilds.
$ emerge-gitclone
$ gzip -cd /proc/config.gz > /usr/src/linux/.configgit -C /var/lib/portage/coreos-overlay \
  checkout "build-${COREOS_RELEASE_VERSION%%.*}" ||
  :  # Stay on master if this version hasn't branched yet.
# Prepare the Linux kernel source for building external modules.
$ emerge -gKv coreos-sources
$ gzip -cd /proc/config.gz > /usr/src/linux/.config
$ make -C /usr/src/linux modules_prepare
$ curl -O https://s3.amazonaws.com/aws-agent.us-east-1/linux/support/AwsAgentKernelModule.tar.gz
$ tar -xzf AwsAgentKernelModule.tar.gz
$ cd AwsAgentKernelModule
# Modify make file and build commands Container Linux
$ make
$ cp amznmon64.ko /lib/modules/4.14.32-coreos/kernel/drivers/aws/amznmon64.ko
# Exit the developer container and delete to save space.
$ rm --force coreos_developer_container.bin
# load module
$ insmod /lib/modules/4.14.32-coreos/kernel/drivers/aws/amznmon64.ko
# verify module is loaded
lsmod | grep amz

References:

Running the agent in a container

# mkdir -p /opt/aws/awsagent
# rkt run \
>   --net=host \
>   --dns=host \
>   --insecure-options=image \
>   --trust-keys-from-https \
>   --volume opt,kind=host,source=/opt/aws/awsagent \
>   --mount volume=opt,target=/opt/aws/awsagent \
>   --interactive \
>   docker://amazonlinux:2
$ yum update
# fetch AWS install script for inspector
$ curl -O https://d1wk0tztpsntt1.cloudfront.net/linux/latest/install
$ yum install which
$ bash install
$ /opt/aws/awsagent/bin/awsagent
2018-04-26 10:55:06 PM:00000218:Notice:Core/LogInfrastructure.cpp:487:Logging subsystems & levels changed
2018-04-26 10:55:06 PM:00000218:Notice:Subscribers/LinuxKernelSubscriber.cpp:248:kernel module inaccessible in non-enforcing mode: /opt/aws/awsagent/kmods/amznmon64.ko
2018-04-26 10:55:06 PM:00000218:Notice:Publishers/ArsenalPublisher.cpp:151:EC2 System detection: 1
2018-04-26 10:55:06 PM:00000218:Notice:Service/InspectorService.cpp:349:Successfully processed startup settings for configuration file /opt/aws/awsagent/etc/agent.cfg : 0
$ ldd /opt/aws/awsagent/bin/awsagent
	linux-vdso.so.1 (0x00007ffd9f1b6000)
	libssl.so.10 => /lib64/libssl.so.10 (0x00007fd320a58000)
	libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007fd3205f6000)
	libpcap.so.1 => not found
	librt.so.1 => /lib64/librt.so.1 (0x00007fd3203ee000)
	libz.so.1 => /lib64/libz.so.1 (0x00007fd3201d8000)
	libm.so.6 => /lib64/libm.so.6 (0x00007fd31fe8d000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fd31fc76000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fd31fa58000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fd31f6a2000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fd32168e000)
	libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007fd31f455000)
	libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007fd31f16d000)
	libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007fd31ef69000)
	libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007fd31ed37000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007fd31eb33000)
	libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007fd31e924000)
	libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007fd31e720000)
	libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fd31e509000)
	libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fd31e2e2000)
	libpcre.so.1 => /lib64/libpcre.so.1 (0x00007fd31e07e000)
@areuthere
Copy link

Do we need to mount the root filesystem of the host also so that inspector can access it for scanning?

Though we are able to install the inspector, it is still having the filesystem of the container. In that case, the inspector would not be able to do what is required here i.e. able to get the security and compliance of applications running on the host. It has only the visibility on the applications running inside a container and not on the host.
Let me know if I am missing something.

@jwieringa
Copy link
Author

@areuthere I never got this working. My focus was on CoreOS which didn't work out how we were being audited. You may have better luck with other systems/control requirements.

Do we need to mount the root filesystem of the host also so that inspector can access it for scanning?

Yes, it is my expectation that the scan needs to look at the root filesystem. Because I never completed the work I'm not confident what that would look like for CoreOS. I suspect that the scanner relies on yum system not present in CoreOS, but again I'm not sure.

@areuthere
Copy link

@jwieringa Thanks for confirming.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment