open-appsec
WebsiteManagement PortalPlaygroundGitHub
  • open-appsec Documentation
  • What is open-appsec?
  • open-appsec Video Tutorials
  • Release Notes
  • Getting started
    • Getting Started
    • Start With Kubernetes
      • Install Using Interactive CLI Tool (Ingress NGINX)
      • Configuration Using Interactive CLI Tool
      • Install Using Helm
      • Install Using Helm - new flow (beta)
      • Configuration Using CRDs
      • Configuration Using CRDs - v1beta2
      • Configuration using CRDs - special options for Large Scale Deployments
        • Using appsec class for assigning separate custom resources to specific deployments
        • Using namespace-scoped custom resources
      • Monitor Events
    • Start With Linux
      • Install open-appsec for Linux
      • Using the open-appsec-ctl Tool
      • Configuration Using Local Policy File (Linux)
      • Local Policy File (Advanced)
      • Local Policy File v1beta2 (beta)
      • Monitor Events
    • Start with Docker
      • Install With Docker (Centrally Managed)
      • Install With Docker (Locally Managed)
      • Deploy With Docker-Compose (Beta)
      • Configuration Using Local Policy File (Docker)
      • Local Policy File (Advanced)
    • Using the Web UI (SaaS)
      • Sign-Up and Login to Portal
      • Agents Deployment
      • Connect Deployed Agents to SaaS Management Using Tool (K8s & Linux)
      • Connect Deployed Agents to SaaS Management Using Helm (K8s)
      • Connect Deployed Agents to SaaS Management (Docker)
      • Create a Profile
      • Protect Additional Assets
      • Monitor Events
    • Using the Advanced Machine Learning Model
  • Concepts
    • Agents
    • Management & Automation
    • Security Practices
    • Contextual Machine Learning
  • SETUP INSTRUCTIONS
    • Setup Web Application Settings
    • Setup Custom Rules and Exceptions
    • Setup Web User Response Pages
    • Setup Log Triggers
    • Setup Behavior Upon Failure
    • Setup Agent Upgrade Schedule
  • Additional Security Engines
    • Anti-Bot
    • API Schema Enforcement
    • Data Loss Prevention (DLP) Rules
    • File Security
    • Intrusion Prevention System (IPS)
    • Rate Limit
  • Snort Rules
    • Import Snort Rules
    • Write Snort Signatures
  • HOW TO
    • Configuration and Learning
      • Track Learning and Move From Learn/Detect to Prevent
      • Configure Contextual Machine Learning for Best Accuracy
      • Track Learning and Local Tuning in Standalone Deployments
      • Move From Detect to Prevent in K8s With Many Ingress Rules
  • Deployment and Upgrade
    • Load the Attachment in Proxy Configuration
    • Upgrade Your Reverse Proxy/API Gateway When an Agent is Installed
    • Integration in GitOps CD (K8s)
    • Build open-appsec Based on Source Code
  • Management Web UI
    • Track Agent Status
    • Delete or Reset Management Tenant (SaaS)
    • Disconnect an open-appsec agent from Central Management
  • Integrations
    • About Integrations With 3rd Party Solutions
    • CrowdSec
      • CrowdSec Bouncer Support
      • CrowdSec Intelligence Sharing Using open-appsec Parser/Scenario
    • NGINX Proxy Manager
      • Install NGINX Proxy Manager with open-appsec managed from NPM WebUI
      • Install NGINX Proxy Manager with open-appsec managed from central WebUI (SaaS)
      • Frequently Asked Questions
      • How to Migrate from an Existing NGINX Proxy Manager Deployment and Keep Configuration
    • NPMplus
    • Docker SWAG
      • Install Docker SWAG with open-appsec (locally managed)
      • How to connect locally managed Docker SWAG with open-appsec to WebUI
      • Install Docker SWAG with open-appsec (centrally managed)
      • Deploy Docker SWAG with docker-compose (beta)
      • Frequently Asked Questions
  • Troubleshooting
    • Troubleshooting
    • Troubleshooting Guides
      • Configuration contains ingress/asset with URL which already has asset attached to it in your tenant
      • HTTP Request to Port 80 Not Returning as Expected
      • Agent Fails to Recognize HTTP Transactions with NGINX
      • Agent Not Recognizing Initial HTTP Requests
      • Handling Large Requests (413 Responses)
      • open-appsec on Docker HTTP Transaction Handler Is Set To Ready
      • Traffic Recognition Issue on Single-Core Machine/Connection Timed Out
      • Installing open-appsec on CentOS 7
      • SELinux: checking status and disabling
      • Deploy open-appsec directly on the web server hosting the application to protect
      • object is locked or remote, and therefore cannot be modified
      • Failed to Register to Fog
  • references
    • Agent CLI
    • Event Query Language
    • Events/Logs Schema
    • WAF Comparison Project
Powered by GitBook
On this page

Was this helpful?

  1. HOW TO
  2. Configuration and Learning

Move From Detect to Prevent in K8s With Many Ingress Rules

Larger K8s environments can have many ingress rules specified within the ingress resource(s) or routes defined for Kong gateway.

Here's a suggested workflow explaining how to set open-appsec to prevent to protect them after initial onboarding was done in detect mode and sufficient time has passed to gain confidence about open-appsec and allow the solution to perform the learning.

Start with your own detect policy, see following example: (Or create a new one and apply to your ingress, see Configuration Using CRDs)

apiVersion: openappsec.io/v1beta1
kind: Policy
metadata:
  name: example-policy
  # BEFORE moving certain ingress rules to prevent-learn
spec:
  default:
    triggers:
    - appsec-special-log-trigger
    mode: detect-learn
    practices:
    - webapp-best-practice
    source-identifiers: my-source-identifiers
    trusted-sources: my-trusted-sources
    custom-response: appsec-web-user-response-example
    exceptions:
    - appsec-exception-example

Once sufficient confidence as well as training is reached for certain resources to move them to prevent: Create specific rules in "prevent-learn" mode in the policy object for those resources (see also the hint below the following example). The learning recommendations as shown in the WebUI will provide helpful suggestions about when to move to prevent for each protected asset, see Track Learning and Move From Learn/Detect to Prevent In the following example the following hosts/path will be protected in "prevent-learn" mode, assuming ingress rules are defined as well to allow the traffic: - web.server.com/example - web.server.com/another-example - another.webserver.com The default mode for all other resources based on existing ingress rules will remain "detect-learn", as specified in the default section of the policy example.

apiVersion: openappsec.io/v1beta1
kind: Policy
metadata:
  name: example-policy
  # AFTER moving certain ingress rules to prevent-learn
spec:
  default:
    triggers:
    - appsec-special-log-trigger
    mode: detect-learn
    practices:
    - webapp-best-practice
    source-identifiers: my-source-identifiers
    trusted-sources: my-trusted-sources
    custom-response: appsec-web-user-response-example
    exceptions:
    - appsec-exception-example
    
  specific-rules:
  - host: web.server.com/example
    triggers:
    - appsec-special-log-trigger
    mode: prevent-learn
    practices:
    - webapp-best-practice
    source-identifiers: my-source-identifiers
    trusted-sources: my-trusted-sources
    custom-response: appsec-web-user-response-example
    exceptions:
    - appsec-exception-example
  - host: web.server.com/another-example
    triggers:
    - appsec-special-log-trigger
    mode: prevent-learn
    practices:
    - webapp-best-practice
    source-identifiers: my-source-identifiers
    trusted-sources: my-trusted-sources
    custom-response: appsec-web-user-response-example
    exceptions:
    - appsec-exception-example
  - host: another.webserver.com
    triggers:
    - appsec-special-log-trigger
    mode: prevent-learn
    practices:
    - webapp-best-practice
    source-identifiers: my-source-identifiers
    trusted-sources: my-trusted-sources
    custom-response: appsec-web-user-response-example
    exceptions:
    - appsec-exception-example

It is possible to create kind of "super rules" in the open-appsec policy that match multiple specific rules in your ingress and reduces effort and complexity, as well of the size of the policy object. Example: For protecting multiple ingress rules that might exist in an ingress resource which are all for the same host "another.webserver.com" (but having different paths defined) it is sufficient to have a single host entry for "another.webserver.com" in the specific-rules section of the open-appsec policy object configured for "prevent-learn" mode (as shown in the above example). Those "super rules" are defined as any other rule in the specific-rules section. With this concept the amount of specific policy rules for open-appsec required to protect a complex environment in K8s can be much lower than the amount of ingress rules defined for it.

PreviousTrack Learning and Local Tuning in Standalone DeploymentsNextDeployment and Upgrade

Last updated 1 year ago

Was this helpful?