# Configuration Using Local Policy File (Linux)

When using open-appsec for NGINX, Kong or APISIX on Linux the configuration can be done in a declarative way using a single YAML file which holds all the relevant configuration objects. \
This way it is compatible with integration in GitOps CD-based processes.

Alternatively management can also soon be done centrally via the open-appsec WebUI (SaaS): [using-the-web-ui-saas](https://docs.openappsec.io/getting-started/using-the-web-ui-saas "mention")

### Location of the declarative configuration file

The default location of the declarative configuration file is here:

`/etc/cp/conf/local_policy.yaml`

You find syntax and schema of the declarative configuration file explained here:\
[local-policy-file-advanced](https://docs.openappsec.io/getting-started/start-with-docker/local-policy-file-advanced "mention")

You can show and edit the full default declarative configuration file with the following command:

`vi /etc/cp/conf/local_policy.yaml` 

or by using the interactive CLI tool `open-appsec-ctl` : [using-the-open-appsec-ctl-tool](https://docs.openappsec.io/getting-started/start-with-linux/using-the-open-appsec-ctl-tool "mention")

### Basic configuration

The default policy within the default configuration file, which is created during the installation, contains the following setting which sets the mode to `detect-learn` for all web resources provided by the NGINX or Kong Gateway:

`policies.default.mode: detect-learn`

If you want attacks instead to be prevented by default for all web resources you can change this as follows:

`policies.default.mode: prevent-learn`

The specific rules section `policies.specific-rules` (v1beta1) / `policies.specificRules` (v1beta2) allows you to create specific rule entries for specific hostnames, hostname-path combinations or paths which override the default policy.

{% hint style="danger" %}
The mode settings defined in the policy for default or specific rules will only have an effect on the actual enforcement for specific security features when the `override-mode` setting in the referenced practice is set to `as-top-level` as this will cause it to inherited the mode setting from the policy.
{% endhint %}

**It is recommended to configure a specific rule for each of your protected web applications and web APIs assets** (starting with `detect-learn` mode, later move to `prevent-learn`).\
\
This allows you to apply a separate enforcement mode setting for each of these protected assets as well as to customize many other settings like selecting the logging configuration, the threat prevention and access control (introduced in v1beta2) practices configuration or selecting a custom-response like a specific response code or a custom block page.

Also the real-time contextual machine learning will be done individually per each configured specific rule representing a protected asset.\
\
Note that the actual configuration settings are all configured by referencing other elements which are defined separately in the configuration file as well, so that you can reuse them multiple times in a kind of object-oriented way, see examples below:

{% tabs %}
{% tab title="v1beta1" %}

```yaml
policies:
  default:
  ...
  ...
  specific-rules:
  - host: "www.my-specific-host.com/my-specific-path"
    triggers:
    - appsec-default-log-trigger
    mode: detect-learn
    practices:
    - webapp-default-practice
    custom-response: appsec-default-web-user-response
```

It is recommended that once sufficient confidence was gained in `detect-learn` mode for an asset which has a specific rule (review the logs) to change the mode for this specific rule to `prevent-learn` mode:

```yaml
policies:
  default:
  ...
  ...
  specific-rules:
  - host: "www.my-specific-host.com/my-specific-path"
    triggers:
    - appsec-default-log-trigger
    mode: prevent-learn
    practices:
    - webapp-default-practice
    custom-response: appsec-default-web-user-response
```

{% endtab %}

{% tab title="v1beta2" %}

```yaml
policies:
  default:
  ...
  ...
  specificRules:
  - host: "www.my-specific-host.com/my-specific-path"
    triggers:
    - appsec-default-log-trigger
    mode: detect-learn
    threatPreventionPractices:
    - webapp-default-practice
    accessControlPractices:
    - webapp-default-practice
    customResponse: appsec-default-web-user-response
```

It is recommended that once sufficient confidence was gained in `detect-learn` mode for an asset which has a specific rule (review the logs) to change the mode for this specific rule to `prevent-learn` mode:

```yaml
policies:
  default:
  ...
  ...
  specificRules:
  - host: "www.my-specific-host.com/my-specific-path"
    triggers:
    - appsec-default-log-trigger
    mode: prevent-learn
    threatPreventionPractices:
    - webapp-default-practice
    accessControlPractices:
    - webapp-default-practice
    customResponse: appsec-default-web-user-response
```

{% endtab %}
{% endtabs %}

### Applying a changed local declarative configuration file 

Once you did any changes to the local declarative configuration file `local_policy.yaml` in order to become active you must apply the new policy:

Use the open-appsec-ctl tool to apply the changes in the policy as follows:

```
open-appsec-ctl --apply-policy
```

### Configuring the local declarative configuration file

On the next page you find the full description for the different configuration sections and elements that can be part of the declarative configuration file:

{% content-ref url="local-policy-file-advanced" %}
[local-policy-file-advanced](https://docs.openappsec.io/getting-started/start-with-linux/local-policy-file-advanced)
{% endcontent-ref %}