Using appsec class for assigning separate custom resources to specific deployments

The advanced configuration options explained on this page require an existing helm-based deployment on K8s with CRD version v1beta2. See here for instructions: Install Using Helm - new flow (beta)

In deployment scenarios with multiple parallel open-appsec deployments on the same Kubernetes cluster (each having same or also different Proxy/API Gateway integration type) often also separate, distinct sets of custom resources for the open-appsec configuration of the different deployments are required.

Starting with open-appsec CRD version v1beta2 you can now define multiple, distinct sets of custom resources for the configuration of different, parallel open-appsec deployments on the same Kubernetes cluster by specifying an appsec class.

Using appsec class

When you deploy open-appsec using helm, you can optionally specify an appsec.className as shown e.g. in the example below to associate that specific appsec class (myCustomClass1 in the example) with your deployment.

helm install ... --set appsec.className=myCustomClass1 ...

As a result, this specific open-appsec deployment (more specifically the open-appsec agent) will only look at those custom resources, which also have the key appsecClassName set to that exact same value.

When you do not specify appsec.className for a deployment of open-appsec, then that open-appsec agent will ignore the appsecClassName property in custom resources and apply both of the following custom resource definitions, those with no appsecClassName set as well as those with an appsecClassName specified with the helm install command.

Here's an example of a policy custom resource with the added property appsecClassName (see line 6) set to myCustomClass1 so that a deployment, which was also configured with appsec.className myCustomClass1 (see above) would consider/implement it:

apiVersion: openappsec.io/v1beta2
kind: Policy
metadata:
    name: policy-example
spec:
    appsecClassName: myCustomClass1
    default:
        mode: detect-learn
        accessControlPractices: [access-control-practice-example]
        threatPreventionPractices: [threat-prevention-practice-example]
        triggers: [log-trigger-example]
        customResponse: custom-response-code-example
        sourceIdentifiers: ""
        trustedSources: ""
        exceptions:
        - exception-example
    specificRules:
        - host: "example.com"
          mode: prevent-learn
          threatPreventionPractices: [threat-prevention-practice-example]
          accessControlPractices: [access-control-practice-example]
          triggers: [log-trigger-example]
          customResponse: custom-response-code-example
          sourceIdentifiers: ""
          trustedSources: ""
          exceptions:
          - exception-example

Make sure to set the appsecClassName property in all custom resources relevant for the specific open-appsec deployment which is configured to using it, including all relevant dependencies (e.g. the custom resources for customResponse, triggers, accessControlPractices, threatPreventionPractices, exceptions as referenced in the example policy custom resource above).

This approach is similar to how you can e.g. set different ingressClassNames to associate which ingress API resources should be satisfied by which Ingress Controllers.

open-appsec deployments without an appsec.className explicitly set, will only apply the configuration from those custom resources, which do not have any appsecClassName explicitly defined.

open-appsec deployments with an appsec.className explicitly set, will only apply the configuration from those custom resources, which do also have the exact same appsecClassName explicitly defined.