• Introduction
• KubeArmor
• Features
• Usage
• Inputs
• Examples
• Troubleshooting
• Contributing

The CI/CD Scan by AccuKnox is a powerful tool designed to enhance the security of your continuous integration and deployment pipelines. By providing comprehensive assessment, monitoring, and protection capabilities, it enables you to:

• Detect and prevent potential supply chain attacks in CI/CD environments
• Gain real-time visibility into your pipeline's security posture
• Streamline the integration of security practices into your DevOps workflow

Ensure application best practices by:

• Applying app hardening policies and checking whether it deviates during GH workflow execution.
• Identifying if there are any unknown processes spawning during CI/CD workflow execution.
• Identifying if any unwanted network connections are started in the pipeline.

In today's fast-paced software development landscape, where operational efficiency is paramount, the CI/CD Scan by AccuKnox empowers DevSecOps teams to deploy with confidence.

KubeArmor is a CNCF project that powers this action to scan the events taking place in the CI/CD environment such as GitHub runner. KubeArmor uses eBPF monitors to watch over the events taking place at system level and uses LSMs (Linux security modules) for enforcing the security policies either in block or audit mode.

To learn more about KubeArmor please visit, https://kubearmor.io/

This action installs KubeArmor in systemd mode in the GitHub runner and watches over the events and enforce security policies safely.

This GitHub action provides you with the necessary information needed for you to monitor and view as the events take place in the CI/CD environment.

We apply standard industry policies as baseline security posture of the CI/CD environment. This helps you to quickly identify if there is a process, network call or file event that is taking place that should be audited or blocked.

We support and apply multiple compliance based security policies that includes

MITRE ATT&CK	NIST	CIS

All of our security policy templates are open sourced and can be found here: Policy Templates

The alerts generated after the scan of your CI/CD pipeline is completed looks like this

It clearly tells you about the policy itself, the command which caused the generation of alert and the message itself, which makes it easy for you to understand the nature of alert and a possible issue in the CI/CD pipeline itself.

Other than providing the baseline as an initial security posture, you can also write your own security policies and have a more granular control on the CI/CD pipeline.

Here is an example of a security policy

apiVersion: security.kubearmor.com/v1
kind: KubeArmorHostPolicy
metadata:
  name: hsp-create-account-create-local-account
spec:
  nodeSelector:
    matchLabels:
      kubearmor.io/hostname: "*" # this is typically replaced by the hostname of your system
  message: Notification! User and password added/modified
  file:
    action: Audit
    matchPaths:
    - path: /etc/passwd
    - path: /etc/shadow
    severity: 3
  process:
    action: Audit
    matchPaths:
    - path: /bin/useradd
    - path: /bin/adduser
    severity: 3
  tags:
  - MITRE
  - T1136.001

As it can be seen in the above policy has Audit action defined for file and process events, any accesses made to the given paths under the matchPaths field would generate an 'Audit' alert from the system that you will be able to see in the report generated by this action.

Please make sure that in kind field you set KubeArmorHostPolicy. To read more about how KubeArmorHost policies are written and designed please take a look at this: KubeArmor policy spec for nodes/VMs

We let you see complete process tree that includes a hierarchical view of the processes taking place in the pipeline, we do not exclude a single process from the view, making sure its easy for you to do a system forensics based analysis.

Here is an example of it:

As you can see, you can clearly observe the parent-child relationship between processes easily and observe the overall system behaviour.

You can also see all the network based events taking place in the system, this is very important to identify any egress or ingress network events with the network protocol, process making the network call and the name of the process itself.

For example:

Support for network policies in coming releases.

The usage is as simple as Plug-and-Play, you only have to include the following lines in your GitHub workflow and you are all set to go.

- name: AccuKnox CI/CD Monitor
  uses: accuknox/report-action@v0

You can also use the latest version of the release, by visting accuknox/report-action GitHub

If you encounter any issues, please feel free to open an issue on the report-action's repository, or mail to [email protected]

The action provides certain inputs to help you control how the scan behaves, we currently provide the following options

Few examples on how you can use the options given

- name: AccuKnox CI/CD Monitor
  uses: accuknox/report-action@v0
  with:
    kubearmor_version: '1.3.8'
    knoxctl_version: '0.6.1'
    dryrun: true

With the above configuration the policies will not be applied on your system, and no policy based alerts will be generated.

- name: AccuKnox CI/CD Monitor
  uses: accuknox/report-action@v0
  with:
    policy_action: "block"

With above configuration you can apply all the policeis in block mode (by default policies are applied in Audit mode)

Please use block mode with caution as it may interrupt certain events or action steps by blocking the operations, this might break the CI/CD pipeline itself.

You can always reach out to help by contacting the report-action maintainers for help, can checkout AccuKnox's help guide or [email protected]

You can contribute to the Github action, all the code exists in ./src directory.

To set things up you need to have nodejs v20 or up and npm

• Install dependencies: npm install

• Build and compile TypeScript code to JavaScript by doing npm run build

The JS compiled code exists in dist directory.

• Run the main and post scripts in seperate shell sessions npm run start:main npm run start:post

• You will need to have KubeArmor (in systemd mode) and knoxctl installed on your system to test the scripts.