Update Managed Rules in Airgapped On-Prem

Update the managed rules in an airgapped on-prem Sysdig installation by mirroring the rules installer image and running it yourself.

Sysdig’s Threat Research Team periodically releases new managed rules that add coverage for new behaviors and exceptions for known good behaviors. See Managed Rules and Releases.

On-prem installations that can reach the internet receive these updates automatically, as described in Managed Policy Updates. In an airgapped installation, the update job can’t pull the rules installer image from the internet, so you mirror the image to your own registry and control when the update runs.

The Rules Installer Image

Sysdig publishes the rules installer as a container image on Quay.io: quay.io/sysdig/falco-rules-installer.

The image contains the managed Falco rules and behavioral analytics rules, and the tooling that validates them and deploys them to the Sysdig backend. When it runs, it does the following:

Validates the rules.
Fetches your custom rules file and verifies that it’s compatible with the managed rules to deploy.
Deploys the rules to the Sysdig backend.

A new image tag is published with each release of the managed rules, and the latest tag always points to the newest release. The tags and their build dates are listed on Quay.io.

Update Managed Rules in an Airgapped Environment

On a machine with internet access, pull the image:
```
docker pull quay.io/sysdig/falco-rules-installer:latest
```
To control which release you deploy, pull a specific tag instead of latest. Choose the tag from the list on Quay.io.

Package the image and transfer it to the airgapped environment:

docker save quay.io/sysdig/falco-rules-installer:latest -o falco-rules-installer.tar

On a machine in the airgapped environment, load the image. This restores both the image and its tags:
```
docker load -i falco-rules-installer.tar
```
Push the image to the airgapped registry that your Sysdig installation uses (global.airgappedRegistryName and global.airgappedRepositoryPrefix in your Helm values), keeping the image name falco-rules-installer.
Run the update. The rules updater, the sysdigcloud-falco-rules-deployer CronJob, pulls the image from that registry each time it runs, using the tag set in rulesDeployer.tag (latest by default). Choose how to run it:
- On the schedule: leave the CronJob enabled. Each time you push a newer image with the tag the CronJob uses, the next scheduled run deploys it. To deploy a specific release, set rulesDeployer.tag to that tag.
- On demand: suspend the CronJob, then start a job from it whenever you want to update:
```
kubectl patch cronjob sysdigcloud-falco-rules-deployer -n <sysdig-namespace> -p '{"spec":{"suspend":true}}'
kubectl create job --from=cronjob/sysdigcloud-falco-rules-deployer rules-deployer-manual -n <sysdig-namespace>
```
  A Helm upgrade restores the CronJob schedule. To suspend it permanently, set rulesDeployer.enabled to false, and use the next option instead.
- From outside the cluster: with rulesDeployer.enabled set to false, run the installer image as a standalone container on any machine that has Docker installed and can reach the Sysdig backend API endpoint. For example:
```
docker run --rm --name falco-rules-installer --network host -it \
  -e DEPLOY_HOSTNAME=https://my-sysdig-backend.com \
  -e DEPLOY_USER_NAME=test@sysdig.com \
  -e DEPLOY_USER_PASSWORD=<my password> \
  -e VALIDATE_RULES=yes \
  -e DEPLOY_RULES=yes \
  -e CREATE_NEW_POLICIES=no \
  -e SDC_SSL_VERIFY=True \
  -e ENV_TYPE=onprem \
  <my-registry>/falco-rules-installer:latest
```

Repeat the steps each time you want to update the managed rules.

Environment Variables

When you run the installer as a standalone container, it reads the following environment variables:

Variable	Description
`DEPLOY_HOSTNAME`	The server that hosts the Sysdig API endpoints. The default is `https://secure.sysdig.com`.
`ENV_TYPE`	The environment to deploy to. Set it to `onprem`.
`DEPLOY_USER_NAME`	The username of an account with admin-level access to the Sysdig API endpoints. The default is a placeholder user, `nobody@nobody.com`.
`DEPLOY_USER_PASSWORD`	The password of the admin user. The default is a placeholder, `nopassword`.
`BEARER_TOKEN`	The Secure API token of an admin account. If set, the installer skips the login and uses the token instead of the username and password. The default is `notset`.
`VALIDATE_RULES`	If `yes`, checks that the rules file is compatible with your custom rules file. Otherwise, skips the validation. The default is `yes`.
`DEPLOY_RULES`	If `yes`, deploys the rules file. Otherwise, skips the deployment. The default is `yes`.
`CREATE_NEW_POLICIES`	If `yes`, fetches new managed runtime policies and restores any missing or deleted ones. It doesn’t overwrite your existing runtime policies. The default is `no`.
`SDC_SSL_VERIFY`	If `false`, allows certificate validation failures when deploying the rules. The default is `true`.