Deploy With Docker-Compose (Beta)
Last updated
Was this helpful?
Last updated
Was this helpful?
The new Docker-Compose deployment options provided here are currently in beta status. You find the current "general availability" deployment instructions for Docker-based platforms here: Install With Docker (Locally Managed) Install With Docker (Centrally Managed)
This new deployment option with Docker-Compose introduces additional containers in case of a standalone deployment (= deployment without any connection to WebUI). These containers introduce some additional functionality, which is relevant for standalone deployments only (already available when connected to central management WebUI): - Local syncing of learning between open-appsec processes and agents - View learning progress on CLI with open-appsec-tuning-tool - Receive configuration recommendations based on the learning progress using the open-appsec-tuning-tool - Receive tuning suggestions and manage them (approve/reject) using the open-appsec-tuning-tool More details on the open-appsec-tuning-tool here: Track Learning and Local Tuning in Standalone Deployments
Linux Docker Host with root permission
Docker-Compose tool installed
(Optional, Recommended) Sign-Up and Login to WebUI Portal If you want to centrally manage your open-appsec WAF deployment via WebUI (SaaS) OR if you want to locally manage your open-appsec WAF deployment but still connect to central WebUI for viewing the local configuration (in read-only), central monitoring, logging and reporting: Follow the instructions below to sign-up and login to the WebUI available at :
(Optional, Recommended) Create deployment profile for the open-appsec deployment in WebUI Portal If you signed-up and logged in to the WebUI Portal (see prerequisite above), now follow the instructions below to create a new deployment profile for your open-appsec deployment. Once done, don't forget to copy the profile token after policy installation as this is needed in the installation steps further below.
Create a folder for your new open-appsec deployment and switch to that folder, e.g.
mkdir open-appsec-deployment
cd ./open-appsec-deployment
Download the docker compose file for your desired open-appsec integration
wget https://raw.githubusercontent.com/openappsec/openappsec/main/deployment/docker-compose/nginx/docker-compose.yaml
# Copyright (C) 2022 Check Point Software Technologies Ltd. All rights reserved.
# Licensed under the Apache License, Version 2.0 (the "License");
# You may obtain a copy of the License at
# http://www.apache.org/licenses/LICENSE-2.0
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
##
## Docker compose file for open-appsec integrated with NGINX
##
version: "3.9"
services:
appsec-agent:
image: ghcr.io/openappsec/agent:${APPSEC_VERSION}
container_name: appsec-agent
environment:
- SHARED_STORAGE_HOST=appsec-shared-storage
- LEARNING_HOST=appsec-smartsync
- TUNING_HOST=appsec-tuning-svc
- https_proxy=${APPSEC_HTTPS_PROXY}
- user_email=${APPSEC_USER_EMAIL}
- AGENT_TOKEN=${APPSEC_AGENT_TOKEN}
- autoPolicyLoad=${APPSEC_AUTO_POLICY_LOAD}
- registered_server="NGINX"
ipc: shareable
restart: unless-stopped
volumes:
- ${APPSEC_CONFIG}:/etc/cp/conf
- ${APPSEC_DATA}:/etc/cp/data
- ${APPSEC_LOGS}:/var/log/nano_agent
- ${APPSEC_LOCALCONFIG}:/ext/appsec
- shm-volume:/dev/shm/check-point
command: /cp-nano-agent
appsec-nginx:
image: ghcr.io/openappsec/nginx-attachment:${APPSEC_VERSION}
container_name: appsec-nginx
ipc: service:appsec-agent
restart: unless-stopped
volumes:
- ${NGINX_CONFIG}:/etc/nginx/conf.d
- shm-volume:/dev/shm/check-point
## advanced configuration - volume mount for nginx.conf file:
## To change global instructions it's possible to also mount your own nginx.conf file by uncommenting the line below
## then specify a desired local folder for NGINX_CONF_FILE in the .env file.
## In the nginx.conf file make sure to include the line starting with "load_module" which loads the appsec attachment
## and is included in /etc/nginx/conf.d/nginx.conf file as part of the nginx-attachment container.
# - ${NGINX_CONF_FILE}:/etc/nginx/nginx.conf
ports:
- "80:80"
- "443:443"
appsec-smartsync:
profiles:
- standalone
image: ghcr.io/openappsec/smartsync:${APPSEC_VERSION}
container_name: appsec-smartsync
environment:
- SHARED_STORAGE_HOST=appsec-shared-storage
restart: unless-stopped
depends_on:
- appsec-shared-storage
appsec-shared-storage:
profiles:
- standalone
image: ghcr.io/openappsec/smartsync-shared-files:${APPSEC_VERSION}
container_name: appsec-shared-storage
ipc: service:appsec-agent
restart: unless-stopped
## if you do not want to run this container as "root" user you can comment it out and instead run the below command after the deployment
## docker exec -u root appsec-shared-storage chown -R appuser:appuser /db
user: root
volumes:
- ${APPSEC_SMART_SYNC_STORAGE}:/db:z
## instead of using local storage for local learning (see line above)
## you can also configure central nfs storage by configuring nfs volume (uncomment the relevant section at end of this file)
## use a shared nfs storage which is recommended in redundant deployments (uncomment line below, comment out the line above)
# - learning_nfs:/db:z
appsec-tuning-svc:
profiles:
- standalone
image: ghcr.io/openappsec/smartsync-tuning:${APPSEC_VERSION}
container_name: appsec-tuning-svc
environment:
- SHARED_STORAGE_HOST=appsec-shared-storage
- QUERY_DB_PASSWORD=${APPSEC_DB_PASSWORD}
- QUERY_DB_HOST=${APPSEC_DB_HOST}
- QUERY_DB_USER=${APPSEC_DB_USER}
## only relevant when deploying own DB
# - SSLMODE:
restart: unless-stopped
volumes:
- ${APPSEC_CONFIG}:/etc/cp/conf
depends_on:
- appsec-shared-storage
- appsec-db
appsec-db:
profiles:
- standalone
image: postgres
container_name: appsec-db
restart: unless-stopped
environment:
- POSTGRES_PASSWORD=${APPSEC_DB_PASSWORD}
- POSTGRES_USER=${APPSEC_DB_USER}
volumes:
- ${APPSEC_POSTGRES_STORAGE}:/var/lib/postgresql/data
## example juice-shop backend container (vulnerable webserver, USE ONLY FOR TESTING AND IN LAB ENV)
juiceshop-backend:
image: bkimminich/juice-shop:latest
container_name: juiceshop-backend
profiles:
- juiceshop
volumes:
shm-volume:
driver: local
driver_opts:
type: tmpfs
device: tmpfs
## advanced configuration: learning_nfs volume for nfs storage in shared_storage container
##
## when configuring nfs storage in shared_storage container configuration above, make sure to also specify learning_nfs volume (see example below for using AWS EFS storage)
##
#volumes:
# learning_nfs:
# driver: local
# driver_opts:
# type: nfs
# o: addr=fs-abcdef.efs.eu-west-1.amazonaws.com,rw,nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport
# device: ":/"
wget https://raw.githubusercontent.com/openappsec/openappsec/main/deployment/docker-compose/nginx-unified/docker-compose.yaml
# Copyright (C) 2022 Check Point Software Technologies Ltd. All rights reserved.
# Licensed under the Apache License, Version 2.0 (the "License");
# You may obtain a copy of the License at
# http://www.apache.org/licenses/LICENSE-2.0
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
##
## Docker compose file for open-appsec deployments of NGINX unified container
##
version: "3.9"
services:
appsec-agent-nginx-unified:
image: ghcr.io/openappsec/agent-unified:${APPSEC_VERSION}
container_name: appsec-agent-nginx-unified
restart: unless-stopped
environment:
- SHARED_STORAGE_HOST=appsec-shared-storage
- LEARNING_HOST=appsec-smartsync
- TUNING_HOST=appsec-tuning-svc
- https_proxy=${APPSEC_HTTPS_PROXY}
- user_email=${APPSEC_USER_EMAIL}
- AGENT_TOKEN=${APPSEC_AGENT_TOKEN}
- autoPolicyLoad=${APPSEC_AUTO_POLICY_LOAD}
ipc: shareable
volumes:
- ${APPSEC_CONFIG}:/etc/cp/conf
- ${APPSEC_DATA}:/etc/cp/data
- ${APPSEC_LOGS}:/var/log/nano_agent
- ${APPSEC_LOCALCONFIG}:/ext/appsec
- ${NGINX_CONFIG}:/etc/nginx/conf.d
## advanced configuration - volume mount for nginx.conf file:
## to change global instructions it's possible to also mount your own nginx.conf file by uncommenting the two lines below
## make sure to include the line starting with "load_module" which loads the appsec attachment
## and is included in /etc/nginx/conf.d/nginx.conf file as part of the nginx-attachment container
# - ${NGINX_CONF_FILE}:/etc/nginx/nginx.conf
ports:
- "80:80"
- "443:443"
command: /cp-nano-agent
appsec-smartsync:
profiles:
- standalone
image: ghcr.io/openappsec/smartsync:${APPSEC_VERSION}
container_name: appsec-smartsync
environment:
- SHARED_STORAGE_HOST=appsec-shared-storage
restart: unless-stopped
depends_on:
- appsec-shared-storage
appsec-shared-storage:
profiles:
- standalone
image: ghcr.io/openappsec/smartsync-shared-files:${APPSEC_VERSION}
container_name: appsec-shared-storage
ipc: service:appsec-agent-nginx-unified
restart: unless-stopped
## if you do not want to run this container as "root" user you can comment it out and instead run the below command after the deployment
## docker exec -u root appsec-shared-storage chown -R appuser:appuser /db
user: root
volumes:
- ${APPSEC_SMART_SYNC_STORAGE}:/db:z
## instead of using local storage for local learning (see line above)
## you can also configure central nfs storage by configuring nfs volume (uncomment the relevant section at end of this file)
## use a shared nfs storage which is recommended in redundant deployments (uncomment line below, comment out the line above)
# - learning_nfs:/db:z
appsec-tuning-svc:
profiles:
- standalone
image: ghcr.io/openappsec/smartsync-tuning:${APPSEC_VERSION}
container_name: appsec-tuning-svc
environment:
- SHARED_STORAGE_HOST=appsec-shared-storage
- QUERY_DB_PASSWORD=${APPSEC_DB_PASSWORD}
- QUERY_DB_HOST=${APPSEC_DB_HOST}
- QUERY_DB_USER=${APPSEC_DB_USER}
## only relevant when deploying own DB
# - SSLMODE:
restart: unless-stopped
volumes:
- ${APPSEC_CONFIG}:/etc/cp/conf
depends_on:
- appsec-shared-storage
- appsec-db
appsec-db:
profiles:
- standalone
image: postgres
container_name: appsec-db
restart: unless-stopped
environment:
- POSTGRES_PASSWORD=${APPSEC_DB_PASSWORD}
- POSTGRES_USER=${APPSEC_DB_USER}
volumes:
- ${APPSEC_POSTGRES_STORAGE}:/var/lib/postgresql/data
## example juice-shop backend container (vulnerable webserver, USE ONLY FOR TESTING AND IN LAB ENV)
juiceshop-backend:
image: bkimminich/juice-shop:latest
container_name: juiceshop-backend
profiles:
- juiceshop
## advanced configuration: learning_nfs volume for nfs storage in shared_storage container
##
## when configuring nfs storage in shared_storage container configuration above, make sure to also specify learning_nfs volume (see example below for using AWS EFS storage)
##
#volumes:
# learning_nfs:
# driver: local
# driver_opts:
# type: nfs
# o: addr=fs-abcdef.efs.eu-west-1.amazonaws.com,rw,nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport
# device: ":/"
wget https://raw.githubusercontent.com/openappsec/openappsec/main/deployment/docker-compose/kong/docker-compose.yaml
# Copyright (C) 2022 Check Point Software Technologies Ltd. All rights reserved.
# Licensed under the Apache License, Version 2.0 (the "License");
# You may obtain a copy of the License at
# http://www.apache.org/licenses/LICENSE-2.0
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
##
## Docker compose file for open-appsec integrated with Kong
##
version: "3.9"
services:
appsec-agent:
image: ghcr.io/openappsec/agent:${APPSEC_VERSION}
container_name: appsec-agent
environment:
- SHARED_STORAGE_HOST=appsec-shared-storage
- LEARNING_HOST=appsec-smartsync
- TUNING_HOST=appsec-tuning-svc
- https_proxy=${APPSEC_HTTPS_PROXY}
- user_email=${APPSEC_USER_EMAIL}
- AGENT_TOKEN=${APPSEC_AGENT_TOKEN}
- autoPolicyLoad=${APPSEC_AUTO_POLICY_LOAD}
- registered_server=Kong
ipc: shareable
restart: unless-stopped
volumes:
- ${APPSEC_CONFIG}:/etc/cp/conf
- ${APPSEC_DATA}:/etc/cp/data
- ${APPSEC_LOGS}:/var/log/nano_agent
- ${APPSEC_LOCALCONFIG}:/ext/appsec
command: /cp-nano-agent
appsec-kong:
image: ghcr.io/openappsec/${KONG_IMAGE}:${APPSEC_VERSION}
container_name: appsec-kong
ipc: service:appsec-agent
## This docker compose deploys Kong in DB-less mode with declarative Kong configuration
## please make sure to have a valid config present in {KONG_CONFIG}:
environment:
- KONG_DATABASE=off
- KONG_DECLARATIVE_CONFIG=/opt/kong/kong.yaml
volumes:
- ${KONG_CONFIG}:/opt/kong
restart: unless-stopped
ports:
- "8000:8000"
- "8443:8443"
- "127.0.0.1:8001:8001"
- "127.0.0.1:8444:8444"
appsec-smartsync:
profiles:
- standalone
image: ghcr.io/openappsec/smartsync:${APPSEC_VERSION}
container_name: appsec-smartsync
environment:
- SHARED_STORAGE_HOST=appsec-shared-storage
restart: unless-stopped
depends_on:
- appsec-shared-storage
appsec-shared-storage:
profiles:
- standalone
image: ghcr.io/openappsec/smartsync-shared-files:${APPSEC_VERSION}
container_name: appsec-shared-storage
ipc: service:appsec-agent
restart: unless-stopped
## if you do not want to run this container as "root" user you can comment it out and instead run the below command after the deployment
## docker exec -u root appsec-shared-storage chown -R appuser:appuser /db
user: root
volumes:
- ${APPSEC_SMART_SYNC_STORAGE}:/db:z
## instead of using local storage for local learning (see line above)
## you can also configure central nfs storage by configuring nfs volume (uncomment the relevant section at end of this file)
## use a shared nfs storage which is recommended in redundant deployments (uncomment line below, comment out the line above)
# - learning_nfs:/db:z
appsec-tuning-svc:
profiles:
- standalone
image: ghcr.io/openappsec/smartsync-tuning:${APPSEC_VERSION}
container_name: appsec-tuning-svc
environment:
- SHARED_STORAGE_HOST=appsec-shared-storage
- QUERY_DB_PASSWORD=${APPSEC_DB_PASSWORD}
- QUERY_DB_HOST=${APPSEC_DB_HOST}
- QUERY_DB_USER=${APPSEC_DB_USER}
## only relevant when deploying own DB
# - SSLMODE:
restart: unless-stopped
volumes:
- ${APPSEC_CONFIG}:/etc/cp/conf
depends_on:
- appsec-shared-storage
- appsec-db
appsec-db:
profiles:
- standalone
image: postgres
container_name: appsec-db
restart: unless-stopped
environment:
- POSTGRES_PASSWORD=${APPSEC_DB_PASSWORD}
- POSTGRES_USER=${APPSEC_DB_USER}
volumes:
- ${APPSEC_POSTGRES_STORAGE}:/var/lib/postgresql/data
## example juice-shop backend container (vulnerable webserver, USE ONLY FOR TESTING AND IN LAB ENV)
juiceshop-backend:
image: bkimminich/juice-shop:latest
container_name: juiceshop-backend
profiles:
- juiceshop
## advanced configuration: learning_nfs volume for nfs storage in shared_storage container
##
## when configuring nfs storage in shared_storage container configuration above, make sure to also specify learning_nfs volume (see example below for using AWS EFS storage)
##
#volumes:
# learning_nfs:
# driver: local
# driver_opts:
# type: nfs
# o: addr=fs-abcdef.efs.eu-west-1.amazonaws.com,rw,nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport
# device: ":/"
wget https://raw.githubusercontent.com/openappsec/openappsec/main/deployment/docker-compose/apisix/docker-compose.yaml
# Copyright (C) 2022 Check Point Software Technologies Ltd. All rights reserved.
# Licensed under the Apache License, Version 2.0 (the "License");
# You may obtain a copy of the License at
# http://www.apache.org/licenses/LICENSE-2.0
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
##
## Docker compose file for open-appsec integrated with APISIX
##
version: "3.9"
services:
appsec-agent:
image: ghcr.io/openappsec/agent:${APPSEC_VERSION}
container_name: appsec-agent
environment:
- SHARED_STORAGE_HOST=appsec-shared-storage
- LEARNING_HOST=appsec-smartsync
- TUNING_HOST=appsec-tuning-svc
- https_proxy=${APPSEC_HTTPS_PROXY}
- user_email=${APPSEC_USER_EMAIL}
- AGENT_TOKEN=${APPSEC_AGENT_TOKEN}
- autoPolicyLoad=${APPSEC_AUTO_POLICY_LOAD}
- registered_server=APISIX
ipc: shareable
restart: unless-stopped
volumes:
- ${APPSEC_CONFIG}:/etc/cp/conf
- ${APPSEC_DATA}:/etc/cp/data
- ${APPSEC_LOGS}:/var/log/nano_agent
- ${APPSEC_LOCALCONFIG}:/ext/appsec
command: /cp-nano-agent
appsec-apisix:
image: ghcr.io/openappsec/apisix-attachment:${APPSEC_VERSION}
container_name: appsec-apisix
ipc: service:appsec-agent
restart: always
environment:
- APISIX_STAND_ALONE=true
volumes:
- ${APISIX_CONFIG}:/usr/local/apisix/conf/apisix.yaml:ro
ports:
- "9080:9080/tcp" # HTTP API port
- "9443:9443/tcp" # HTTPS API port
- "9180:9180/tcp" # Admin API HTTP port
- "9091:9091/tcp" # Admin API HTTPS port
appsec-smartsync:
profiles:
- standalone
image: ghcr.io/openappsec/smartsync:${APPSEC_VERSION}
container_name: appsec-smartsync
environment:
- SHARED_STORAGE_HOST=appsec-shared-storage
restart: always
depends_on:
- appsec-shared-storage
appsec-shared-storage:
profiles:
- standalone
image: ghcr.io/openappsec/smartsync-shared-files:${APPSEC_VERSION}
container_name: appsec-shared-storage
ipc: service:appsec-agent
restart: always
## if you do not want to run this container as "root" user you can comment it out and instead run the below command after the deployment
## docker exec -u root appsec-shared-storage chown -R appuser:appuser /db
user: root
volumes:
- ${APPSEC_SMART_SYNC_STORAGE}:/db:z
## instead of using local storage for local learning (see line above)
## you can also configure central nfs storage by configuring nfs volume (uncomment the relevant section at end of this file)
## use a shared nfs storage which is recommended in redundant deployments (uncomment line below, comment out the line above)
# - learning_nfs:/db:z
appsec-tuning-svc:
profiles:
- standalone
image: ghcr.io/openappsec/smartsync-tuning:${APPSEC_VERSION}
container_name: appsec-tuning-svc
environment:
- SHARED_STORAGE_HOST=appsec-shared-storage
- QUERY_DB_PASSWORD=${APPSEC_DB_PASSWORD}
- QUERY_DB_HOST=${APPSEC_DB_HOST}
- QUERY_DB_USER=${APPSEC_DB_USER}
## only relevant when deploying own DB
# - SSLMODE:
restart: always
volumes:
- ${APPSEC_CONFIG}:/etc/cp/conf
depends_on:
- appsec-shared-storage
- appsec-db
appsec-db:
profiles:
- standalone
image: postgres
container_name: appsec-db
restart: always
environment:
- POSTGRES_PASSWORD=${APPSEC_DB_PASSWORD}
- POSTGRES_USER=${APPSEC_DB_USER}
volumes:
- ${APPSEC_POSTGRES_STORAGE}:/var/lib/postgresql/data
## example juice-shop backend container (vulnerable webserver, USE ONLY FOR TESTING AND IN LAB ENV)
juiceshop-backend:
image: bkimminich/juice-shop:latest
container_name: juiceshop-backend
## advanced configuration: learning_nfs volume for nfs storage in shared_storage container
##
## when configuring nfs storage in shared_storage container configuration above, make sure to also specify learning_nfs volume (see example below for using AWS EFS storage)
##
#volumes:
# learning_nfs:
# driver: local
# driver_opts:
# type: nfs
# o: addr=fs-abcdef.efs.eu-west-1.amazonaws.com,rw,nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport
# device: ":/"
wget https://raw.githubusercontent.com/openappsec/openappsec/main/deployment/docker-compose/envoy/docker-compose.yaml
# Copyright (C) 2022 Check Point Software Technologies Ltd. All rights reserved.
# Licensed under the Apache License, Version 2.0 (the "License");
# You may obtain a copy of the License at
# http://www.apache.org/licenses/LICENSE-2.0
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
##
## Docker compose file for open-appsec integrated with Envoy
##
version: "3.9"
services:
appsec-agent:
image: ghcr.io/openappsec/agent:${APPSEC_VERSION}
container_name: appsec-agent
environment:
- SHARED_STORAGE_HOST=appsec-shared-storage
- LEARNING_HOST=appsec-smartsync
- TUNING_HOST=appsec-tuning-svc
- https_proxy=${APPSEC_HTTPS_PROXY}
- user_email=${APPSEC_USER_EMAIL}
- AGENT_TOKEN=${APPSEC_AGENT_TOKEN}
- autoPolicyLoad=${APPSEC_AUTO_POLICY_LOAD}
- registered_server="Envoy"
ipc: shareable
restart: unless-stopped
volumes:
- ${APPSEC_CONFIG}:/etc/cp/conf
- ${APPSEC_DATA}:/etc/cp/data
- ${APPSEC_LOGS}:/var/log/nano_agent
- ${APPSEC_LOCALCONFIG}:/ext/appsec
command: /cp-nano-agent
appsec-envoy:
image: ghcr.io/openappsec/envoy-attachment:${APPSEC_VERSION}
container_name: appsec-envoy
ipc: service:appsec-agent
restart: unless-stopped
environment:
- ENVOY_UID=0
- CONCURRENCY_CALC=${ENVOY_CONCURRENCY_CALC}
- CONCURRENCY_NUMBER=${ENVOY_CONCURRENCY_NUMBER}
volumes:
- ${ENVOY_CONFIG}:/envoy.yaml
command: -c /envoy.yaml
## If required you can adjust the amount of worker threads envoy will run by commenting out the line above and uncommenting the line below
## then specify ENVOY_CONCURRENCY parameter with the desired thread amount in the .env file.
## By default there's one worker thread per virtual CPU (vCPU) core available on the machine.
# command: -c /envoy.yaml --concurrency ${ENVOY_CONCURRENCY}
ports:
- "80:80"
- "443:443"
appsec-smartsync:
profiles:
- standalone
image: ghcr.io/openappsec/smartsync:${APPSEC_VERSION}
container_name: appsec-smartsync
environment:
- SHARED_STORAGE_HOST=appsec-shared-storage
restart: unless-stopped
depends_on:
- appsec-shared-storage
appsec-shared-storage:
profiles:
- standalone
image: ghcr.io/openappsec/smartsync-shared-files:${APPSEC_VERSION}
container_name: appsec-shared-storage
ipc: service:appsec-agent
restart: unless-stopped
## if you do not want to run this container as "root" user you can comment it out and instead run the below command after the deployment
## docker exec -u root appsec-shared-storage chown -R appuser:appuser /db
user: root
volumes:
- ${APPSEC_SMART_SYNC_STORAGE}:/db:z
## instead of using local storage for local learning (see line above)
## you can also configure central nfs storage by configuring nfs volume (uncomment the relevant section at end of this file)
## use a shared nfs storage which is recommended in redundant deployments (uncomment line below, comment out the line above)
# - learning_nfs:/db:z
appsec-tuning-svc:
profiles:
- standalone
image: ghcr.io/openappsec/smartsync-tuning:${APPSEC_VERSION}
container_name: appsec-tuning-svc
environment:
- SHARED_STORAGE_HOST=appsec-shared-storage
- QUERY_DB_PASSWORD=${APPSEC_DB_PASSWORD}
- QUERY_DB_HOST=${APPSEC_DB_HOST}
- QUERY_DB_USER=${APPSEC_DB_USER}
## only relevant when deploying own DB
# - SSLMODE:
restart: unless-stopped
volumes:
- ${APPSEC_CONFIG}:/etc/cp/conf
depends_on:
- appsec-shared-storage
- appsec-db
appsec-db:
profiles:
- standalone
image: postgres
container_name: appsec-db
restart: unless-stopped
environment:
- POSTGRES_PASSWORD=${APPSEC_DB_PASSWORD}
- POSTGRES_USER=${APPSEC_DB_USER}
volumes:
- ${APPSEC_POSTGRES_STORAGE}:/var/lib/postgresql/data
## example juice-shop backend container (vulnerable webserver, USE ONLY FOR TESTING AND IN LAB ENV)
juiceshop-backend:
image: bkimminich/juice-shop:latest
container_name: juiceshop-backend
## advanced configuration: learning_nfs volume for nfs storage in shared_storage container
##
## when configuring nfs storage in shared_storage container configuration above, make sure to also specify learning_nfs volume (see example below for using AWS EFS storage)
##
#volumes:
# learning_nfs:
# driver: local
# driver_opts:
# type: nfs
# o: addr=fs-abcdef.efs.eu-west-1.amazonaws.com,rw,nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport
# device: ":/"
Download the .env
file for your desired open-appsec integration and adjust the configuration to your requirements as described below:
Download the default .env
file here:
wget https://raw.githubusercontent.com/openappsec/openappsec/main/deployment/docker-compose/nginx/.env
## .env file for docker-compose deployments of open-appsec integrated with NGINX
## for more info see https://docs.openappsec.io
APPSEC_VERSION=latest
APPSEC_CONFIG=./appsec-config
APPSEC_DATA=./appsec-data
APPSEC_LOGS=./appsec-logs
APPSEC_LOCALCONFIG=./appsec-localconfig
## Make sure the parameter APPSEC_AUTO_POLICY_LOAD is set to false when centrally managing
## open-appsec configuration via open-appsec Web UI.
## You can optionally set it to true when using local, declarative management for open-appsec,
## declarative configuration will then get applied automatically when changed.
APPSEC_AUTO_POLICY_LOAD=false
## Example for configuring HTTPS Proxy:
## APPSEC_HTTPS_PROXY=user:password@proxy_address:port
APPSEC_HTTPS_PROXY=
APPSEC_SMART_SYNC_STORAGE=./appsec-smartsync-storage
APPSEC_USER_EMAIL=user@email.com
APPSEC_DB_PASSWORD=pass
APPSEC_DB_USER=postgres
APPSEC_DB_HOST=appsec-db
APPSEC_POSTGRES_STORAGE=./appsec-postgres-data
## Make sure to have a valid NGINX configuration file default.conf in the folder specified for NGINX_CONFIG.
## For deployment of a simple lab testing environment, you can deploy the example configuration provided
## for the vulnerable juice-shop container, see instructions further below.
NGINX_CONFIG=./nginx-config
## To connect your deployment to central open-appsec WebUI provide the token for a profile
## which you created in open-appsec WebUI at https://my.openappsec.io
## Example: APPSEC_AGENT_TOKEN=111-22222-111
APPSEC_AGENT_TOKEN=
## Important: When not providing token for connection to central WebUI:
## Make sure to add the value "standalone" to the COMPOSE_PROFILES value, this will enable
## sharing of learning between processes and allow you to perform tuning locally on CLI
COMPOSE_PROFILES=
## JUICE SHOP DEMO CONTAINER:
## In order to deploy the optional, additional, vulnerable juiceshop container (for demo and testing purposes only!):
## Add the value "juiceshop" to the COMPOSE_PROFILES value above.
## Make sure to also adjust the nginx.conf file in NGINX_CONFIG folder
## to include a proxy_pass directive forwarding external traffic on e.g. port 80 to the juiceshop-backend container
## you can use the example file available here:
## https://raw.githubusercontent.com/openappsec/openappsec/main/examples/juiceshop/envoy/envoy.yaml
## place the file above in NGINX_CONFIG folder
## note that juiceshop container listens on HTTP port 3000 by default
## Note that COMPOSE_PROFILES can also receive multiple values, e.g. as shown here:
## COMPOSE_PROFILES=standalone,juiceshop
If you created a deployment profile in the WebUI and copied the Token from it:
Edit the .env
file and add your token to the key APPSEC_AGENT_TOKEN
.
If you did not create a deployment profile in the WebUI and do not want to connect your deployment to central WebUI (SaaS) at all:
Set the value standalone
for the key COMPOSE_PROFILES
which will activate the deployment of additional containers which are required only when not connected to the WebUI at all (resulting in standalone, locally, declaratively managed deployment).
Replace user@email.com
in the .env file with your own email. (More details below.)
.env
file allowing further customization of the deployment:APPSEC_AGENT_TOKEN: For connecting your open-appsec deployment to central WebUI set APPSEC_AGENT_TOKEN to your own deployment profile token as copied from profile settings in the open-appsec central WebUI (see section Prerequisites above).
COMPOSE_PROFILES: Possible values you can set for this key: (you can set multiple values, separated by comma)
standalone
: This will activate the deployment of additional containers which are required only when you are not connected to the WebUI at all, resulting in standalone, locally, declaratively managed deployment.
Only activate the standalone
profile in case you did not set a WebUI deployment profile token as value for the APPSEC_AGENT_TOKEN key (see above)!
Do not activate the juiceshop profile in production environments as the juiceshop container is intentionally highly vulnerable and meant for testing in lab environments only!
USER_EMAIL: (Optional) Associate your email address with your specific deployment by replacing user@email.com
with your own email address.
This allows the open-appsec team to provide you easy assistance in case of any issues you might have with your specific deployment in the future and also to provide you information proactively regarding open-appsec in general or regarding your specific deployment. This is an optional parameter and can be removed. If we send automatic emails there will also be an opt-out option included for receiving similar communication in the future.
APPSEC_HTTPS_PROXY: (Optional) Configure an HTTP(S) proxy server to be used by the agent.
APPSEC_AUTO_POLICY_LOAD: (Optional) When set to true
, allows you to set the open-appsec agent to automatically apply any new changes in the local_policy.yaml file without having to restart the agent container or applying the changes with open-appsec-ctl -ap
(note that this can take up to 30 seconds). This is useful especially in DevOps scenarios with continuous deployment scenarios.
APPSEC_VERSION: Allows you to specify a specific version for deployment instead of using the default latest
version for the containers provided by open-appsec (not relevant for postgres container).
Additional configuration available specifically for this integration type:
NGINX_CONFIG: Set the directory on the docker host used for the volume mount to the NGINX conf.d
directory. Make sure to have a valid NGINX configuration file default.conf in the mounted directory.
For testing purposes in a lab environment you can activate the deployment of the vulnerable juiceshop-backend container via COMPOSE_PROFILES
key (see above) and then deploy the available configuration example for exposing it via the proxy, which is provided by the open-appsec team (download link is provided in the .env file).
You find some additional advanced configuration options described within the docker-compose.yaml
file as comments.
Download the default .env
file here:
wget https://raw.githubusercontent.com/openappsec/openappsec/main/deployment/docker-compose/nginx-unified/.env
## .env file for docker-compose deployments of open-appsec NGINX unified container
## for more info see https://docs.openappsec.io
APPSEC_VERSION=latest
APPSEC_CONFIG=./appsec-config
APPSEC_DATA=./appsec-data
APPSEC_LOGS=./appsec-logs
APPSEC_LOCALCONFIG=./appsec-localconfig
## Make sure the parameter APPSEC_AUTO_POLICY_LOAD is set to false when centrally managing
## open-appsec configuration via open-appsec Web UI.
## You can optionally set it to true when using local, declarative management for open-appsec,
## declarative configuration will then get applied automatically when changed.
APPSEC_AUTO_POLICY_LOAD=false
## Example for configuring HTTPS Proxy:
## APPSEC_HTTPS_PROXY=user:password@proxy_address:port
APPSEC_HTTPS_PROXY=
APPSEC_SMART_SYNC_STORAGE=./appsec-smartsync-storage
APPSEC_USER_EMAIL=user@email.com
APPSEC_DB_PASSWORD=pass
APPSEC_DB_USER=postgres
APPSEC_DB_HOST=appsec-db
APPSEC_POSTGRES_STORAGE=./appsec-postgres-data
## Make sure to have a valid NGINX configuration file default.conf in the folder specified for NGINX_CONFIG.
## For deployment of a simple lab testing environment, you can deploy the example configuration provided
## for the vulnerable juice-shop container, see instructions further below.
NGINX_CONFIG=./nginx-config
## To connect your deployment to central open-appsec WebUI provide the token for a profile
## which you created in open-appsec WebUI at https://my.openappsec.io
## Example: APPSEC_AGENT_TOKEN=111-22222-111
APPSEC_AGENT_TOKEN=
## Important: When not providing token for connection to central WebUI:
## Make sure to add the value "standalone" to the COMPOSE_PROFILES value, this will enable
## sharing of learning between processes and allow you to perform tuning locally on CLI
COMPOSE_PROFILES=
## JUICE SHOP DEMO CONTAINER:
## In order to deploy the optional, additional, vulnerable juiceshop container (for demo and testing purposes only!):
## Add the value "juiceshop" to the COMPOSE_PROFILES value above.
## Make sure to also adjust the nginx.conf file in NGINX_CONFIG folder
## to include a proxy_pass directive forwarding external traffic on e.g. port 80 to the juiceshop-backend container
## you can use the example file available here:
## https://raw.githubusercontent.com/openappsec/openappsec/examples/juiceshop/nginx/default.conf
## place the file above in NGINX_CONFIG folder
## note that juiceshop container listens on HTTP port 3000 by default
## Note that COMPOSE_PROFILES can also receive multiple values, e.g. as shown here:
## COMPOSE_PROFILES=standalone,juiceshop
If you created a deployment profile in the WebUI and copied the Token from it:
Edit the .env
file and add your token to the key APPSEC_AGENT_TOKEN
.
If you did not create a deployment profile in the WebUI and do not want to connect your deployment to central WebUI (SaaS) at all:
Set the value standalone
for the key COMPOSE_PROFILES
which will activate the deployment of additional containers which are required only when not connected to the WebUI at all (resulting in standalone, locally, declaratively managed deployment).
Replace user@email.com
in the .env file with your own email. (More details below.)
.env
file allowing further customization of the deployment:APPSEC_AGENT_TOKEN: For connecting your open-appsec deployment to central WebUI set APPSEC_AGENT_TOKEN to your own deployment profile token as copied from profile settings in the open-appsec central WebUI (see section Prerequisites above).
COMPOSE_PROFILES: Possible values you can set for this key: (you can set multiple values, separated by comma)
standalone
: This will activate the deployment of additional containers which are required only when you are not connected to the WebUI at all, resulting in standalone, locally, declaratively managed deployment.
Only activate the standalone
profile in case you did not set a WebUI deployment profile token as value for the APPSEC_AGENT_TOKEN key (see above)!
juiceshop
: This will deploy an additional, vulnerable juiceshop-backend container that can be used for demo and testing purposes.
Do not activate the juiceshop profile in production environments as the juiceshop container is intentionally highly vulnerable and meant for testing in lab environments only!
USER_EMAIL: (Optional) Associate your email address with your specific deployment by replacing user@email.com
with your own email address.
This allows the open-appsec team to provide you easy assistance in case of any issues you might have with your specific deployment in the future and also to provide you information proactively regarding open-appsec in general or regarding your specific deployment. This is an optional parameter and can be removed. If we send automatic emails there will also be an opt-out option included for receiving similar communication in the future.
APPSEC_HTTPS_PROXY: (Optional) Configure an HTTP(S) proxy server to be used by the agent.
APPSEC_AUTO_POLICY_LOAD: (Optional) When set to true
, allows you to set the open-appsec agent to automatically apply any new changes in the local_policy.yaml file without having to restart the agent container or applying the changes with open-appsec-ctl -ap
(note that this can take up to 30 seconds). This is useful especially in DevOps scenarios with continuous deployment scenarios.
APPSEC_VERSION: Allows you to specify a specific version for deployment instead of using the default latest
version for the containers provided by open-appsec (not relevant for postgres container).
Additional configuration available specifically for this integration type:
NGINX_CONFIG: Set the directory on the docker host used for the volume mount to the NGINX conf.d
directory. Make sure to have a valid NGINX configuration file default.conf in the mounted directory.
For testing purposes in a lab environment you can activate the deployment of the vulnerable juiceshop-backend container via COMPOSE_PROFILES
key (see above) and then deploy the available configuration example for exposing it via the proxy, which is provided by the open-appsec team (download link is provided in the .env file).
You find some additional advanced configuration options described within the docker-compose.yaml
file as comments.
Download the default .env
file here:
wget https://raw.githubusercontent.com/openappsec/openappsec/main/deployment/docker-compose/kong/.env
## .env file for docker-compose deployments of open-appsec integrated with Kong
## for more info see https://docs.openappsec.io
APPSEC_VERSION=latest
APPSEC_CONFIG=./appsec-config
APPSEC_DATA=./appsec-data
APPSEC_LOGS=./appsec-logs
APPSEC_LOCALCONFIG=./appsec-localconfig
## Make sure the parameter APPSEC_AUTO_POLICY_LOAD is set to false when centrally managing
## open-appsec configuration via open-appsec Web UI.
## You can optionally set it to true when using local, declarative management for open-appsec,
## declarative configuration will then get applied automatically when changed.
APPSEC_AUTO_POLICY_LOAD=false
## Example for configuring HTTPS Proxy:
## APPSEC_HTTPS_PROXY=user:password@proxy_address:port
APPSEC_HTTPS_PROXY=
APPSEC_SMART_SYNC_STORAGE=./appsec-smartsync-storage
APPSEC_USER_EMAIL=user@email.com
APPSEC_DB_PASSWORD=pass
APPSEC_DB_USER=postgres
APPSEC_DB_HOST=appsec-db
APPSEC_POSTGRES_STORAGE=./appsec-postgres-data
## Make sure to have a valid Kong declarative configuration file kong.yaml in the folder specified for KONG_CONFIG.
## For deployment of a simple lab testing environment, you can deploy the example configuration provided
## for the vulnerable juice-shop container, see instructions further below.
KONG_CONFIG=./kong-config
## For Kong Gateway Enterprise Edition set KONG_IMAGE to kong-gateway-attachment instead of kong-attachment
KONG_IMAGE=kong-attachment
## To connect your deployment to central open-appsec WebUI provide the token for a profile
## which you created in open-appsec WebUI at https://my.openappsec.io
## Example: APPSEC_AGENT_TOKEN=111-22222-111
APPSEC_AGENT_TOKEN=
## Important: When not providing token for connection to central WebUI:
## Make sure to add the value "standalone" to the COMPOSE_PROFILES value, this will enable
## sharing of learning between processes and allow you to perform tuning locally on CLI
COMPOSE_PROFILES=
## JUICE SHOP DEMO CONTAINER:
## In order to deploy the optional, additional, vulnerable juiceshop container (for demo and testing purposes only!):
## Add the value "juiceshop" to the COMPOSE_PROFILES value above.
## Make sure to also adjust the kong.yaml file in KONG_CONFIG folder
## to include service and route configuration for forwarding external traffic to the juiceshop-backend container
## (kong listens by default for HTTP/HTTPS on port 8000/8443)
## you can use the example file available here:
## https://raw.githubusercontent.com/openappsec/openappsec/examples/juiceshop/kong/kong.yaml
## note that juiceshop container listens on HTTP port 3000 by default
## Note that COMPOSE_PROFILES can also receive multiple values, e.g. as shown here:
## COMPOSE_PROFILES=standalone,juiceshop
If you created a deployment profile in the WebUI and copied the Token from it:
Edit the .env
file and add your token to the key APPSEC_AGENT_TOKEN
.
If you did not create a deployment profile in the WebUI and do not want to connect your deployment to central WebUI (SaaS) at all:
Set the value standalone
for the key COMPOSE_PROFILES
which will activate the deployment of additional containers which are required only when not connected to the WebUI at all (resulting in standalone, locally, declaratively managed deployment).
Replace user@email.com
in the .env file with your own email. (More details below.)
.env
file allowing further customization of the deployment:APPSEC_AGENT_TOKEN: For connecting your open-appsec deployment to central WebUI set APPSEC_AGENT_TOKEN to your own deployment profile token as copied from profile settings in the open-appsec central WebUI (see section Prerequisites above).
COMPOSE_PROFILES: Possible values you can set for this key: (you can set multiple values, separated by comma)
standalone
: This will activate the deployment of additional containers which are required only when you are not connected to the WebUI at all, resulting in standalone, locally, declaratively managed deployment.
Only activate the standalone
profile in case you did not set a WebUI deployment profile token as value for the APPSEC_AGENT_TOKEN key (see above)!
juiceshop
: This will deploy an additional, vulnerable juiceshop-backend container that can be used for demo and testing purposes.
Do not activate the juiceshop profile in production environments as the juiceshop container is intentionally highly vulnerable and meant for testing in lab environments only!
USER_EMAIL: (Optional) Associate your email address with your specific deployment by replacing user@email.com
with your own email address.
This allows the open-appsec team to provide you easy assistance in case of any issues you might have with your specific deployment in the future and also to provide you information proactively regarding open-appsec in general or regarding your specific deployment. This is an optional parameter and can be removed. If we send automatic emails there will also be an opt-out option included for receiving similar communication in the future.
APPSEC_HTTPS_PROXY: (Optional) Configure an HTTP(S) proxy server to be used by the agent.
APPSEC_AUTO_POLICY_LOAD: (Optional) When set to true
, allows you to set the open-appsec agent to automatically apply any new changes in the local_policy.yaml file without having to restart the agent container or applying the changes with open-appsec-ctl -ap
(note that this can take up to 30 seconds). This is useful especially in DevOps scenarios with continuous deployment scenarios.
APPSEC_VERSION: Allows you to specify a specific version for deployment instead of using the default latest
version for the containers provided by open-appsec (not relevant for postgres container).
Additional configuration available specifically for this integration type:
KONG_CONFIG: Set the directory on the docker host used for the volume mount to the Kong /opt/kong
directory. Make sure to have a valid Kong declarative configuration file kong.yaml in the mounted directory.
For testing purposes in a lab environment you can activate the deployment of the vulnerable juiceshop-backend container via COMPOSE_PROFILES
key (see above) and then deploy the available configuration example for exposing it via the proxy, which is provided by the open-appsec team (download link is provided in the .env file).
You find some additional advanced configuration options described within the docker-compose.yaml
file as comments.
Download the default .env
file here:
wget https://raw.githubusercontent.com/openappsec/openappsec/main/deployment/docker-compose/apisix/.env
## .env file for docker-compose deployments of open-appsec integrated with APISIX
## for more info see https://docs.openappsec.io
APPSEC_VERSION=latest
APPSEC_CONFIG=./appsec-config
APPSEC_DATA=./appsec-data
APPSEC_LOGS=./appsec-logs
APPSEC_LOCALCONFIG=./appsec-localconfig
## Make sure the parameter APPSEC_AUTO_POLICY_LOAD is set to false when centrally managing
## open-appsec configuration via open-appsec Web UI.
## You can optionally set it to true when using local, declarative management for open-appsec,
## declarative configuration will then get applied automatically when changed.
APPSEC_AUTO_POLICY_LOAD=false
## Example for configuring HTTPS Proxy:
## APPSEC_HTTPS_PROXY=user:password@proxy_address:port
APPSEC_HTTPS_PROXY=
APPSEC_SMART_SYNC_STORAGE=./appsec-smartsync-storage
APPSEC_USER_EMAIL=user@email.com
APPSEC_DB_PASSWORD=pass
APPSEC_DB_USER=postgres
APPSEC_DB_HOST=appsec-db
APPSEC_POSTGRES_STORAGE=./appsec-postgres-data
## Make sure to have a valid apisix configuration for APISIX in standalone mode in the following file:
## For deployment of a simple lab testing environment, you can deploy the example configuration provided
## for the vulnerable juice-shop container, see instructions further below.
APISIX_CONFIG=./apisix-config/apisix.yaml
## To connect your deployment to central open-appsec WebUI provide the token for a profile
## which you created in open-appsec WebUI at https://my.openappsec.io
## Example: APPSEC_AGENT_TOKEN=111-22222-111
APPSEC_AGENT_TOKEN=
## Important: When not providing token for connection to central WebUI:
## Make sure to add the value "standalone" to the COMPOSE_PROFILES value, this will enable
## sharing of learning between processes and allow you to perform tuning locally on CLI
COMPOSE_PROFILES=
## JUICE SHOP DEMO CONTAINER:
## In order to deploy the optional, additional, vulnerable juiceshop container (for demo and testing purposes only!):
## Add the value "juiceshop" to the COMPOSE_PROFILES value above.
## Make sure to also adjust the apisix.yaml file in APISIX_CONFIG folder
## to include route and node configuration for forwarding external traffic to the juiceshop-backend container
## (apisix listens by default for HTTP/HTTPS on port 9080/9443)
## you can use the example file available here:
## https://raw.githubusercontent.com/openappsec/openappsec/refs/heads/main/examples/juiceshop/apisix.yaml
## in the appsec-apisix service definition
## note that juiceshop container listens on HTTP port 3000 by default
## Note that COMPOSE_PROFILES can also receive multiple values, e.g. as shown here:
## COMPOSE_PROFILES=standalone,juiceshop
If you created a deployment profile in the WebUI and copied the Token from it:
Edit the .env
file and add your token to the key APPSEC_AGENT_TOKEN
.
If you did not create a deployment profile in the WebUI and do not want to connect your deployment to central WebUI (SaaS) at all:
Set the value standalone
for the key COMPOSE_PROFILES
which will activate the deployment of additional containers which are required only when not connected to the WebUI at all (resulting in standalone, locally, declaratively managed deployment).
Replace user@email.com
in the .env file with your own email. (More details below.)
.env
file allowing further customization of the deployment:APPSEC_AGENT_TOKEN: For connecting your open-appsec deployment to central WebUI set APPSEC_AGENT_TOKEN to your own deployment profile token as copied from profile settings in the open-appsec central WebUI (see section Prerequisites above).
COMPOSE_PROFILES: Possible values you can set for this key: (you can set multiple values, separated by comma)
standalone
: This will activate the deployment of additional containers which are required only when you are not connected to the WebUI at all, resulting in standalone, locally, declaratively managed deployment.
Only activate the standalone
profile in case you did not set a WebUI deployment profile token as value for the APPSEC_AGENT_TOKEN key (see above)!
juiceshop
: This will deploy an additional, vulnerable juiceshop-backend container that can be used for demo and testing purposes.
Do not activate the juiceshop profile in production environments as the juiceshop container is intentionally highly vulnerable and meant for testing in lab environments only!
USER_EMAIL: (Optional) Associate your email address with your specific deployment by replacing user@email.com
with your own email address.
This allows the open-appsec team to provide you easy assistance in case of any issues you might have with your specific deployment in the future and also to provide you information proactively regarding open-appsec in general or regarding your specific deployment. This is an optional parameter and can be removed. If we send automatic emails there will also be an opt-out option included for receiving similar communication in the future.
APPSEC_HTTPS_PROXY: (Optional) Configure an HTTP(S) proxy server to be used by the agent.
APPSEC_AUTO_POLICY_LOAD: (Optional) When set to true
, allows you to set the open-appsec agent to automatically apply any new changes in the local_policy.yaml file without having to restart the agent container or applying the changes with open-appsec-ctl -ap
(note that this can take up to 30 seconds). This is useful especially in DevOps scenarios with continuous deployment scenarios.
APPSEC_VERSION: Allows you to specify a specific version for deployment instead of using the default latest
version for the containers provided by open-appsec (not relevant for postgres container).
Additional configuration available specifically for this integration type:
APISIX_CONFIG: Set the directory on the docker host used for the APISIX configuration file mount to the APISIX file path /usr/local/apisix/conf/apisix.yaml
. Make sure to have a valid apisix configuration for APISIX in standalone mode in the mounted file.
For testing purposes in a lab environment you can activate the deployment of the vulnerable juiceshop-backend container via COMPOSE_PROFILES
key (see above) and then deploy the available configuration example for exposing it via the proxy, which is provided by the open-appsec team (download link is provided in the .env file).
You find some additional advanced configuration options described within the docker-compose.yaml
file as comments.
Download the default .env
file here:
wget https://raw.githubusercontent.com/openappsec/openappsec/main/deployment/docker-compose/envoy/.env
## .env file for docker-compose deployments of open-appsec integrated with Envoy
## for more info see https://docs.openappsec.io
APPSEC_VERSION=latest
APPSEC_CONFIG=./appsec-config
APPSEC_DATA=./appsec-data
APPSEC_LOGS=./appsec-logs
APPSEC_LOCALCONFIG=./appsec-localconfig
## Make sure the parameter APPSEC_AUTO_POLICY_LOAD is set to false when centrally managing
## open-appsec configuration via open-appsec Web UI.
## You can optionally set it to true when using local, declarative management for open-appsec,
## declarative configuration will then get applied automatically when changed.
APPSEC_AUTO_POLICY_LOAD=false
## Example for configuring HTTPS Proxy:
## APPSEC_HTTPS_PROXY=user:password@proxy_address:port
APPSEC_HTTPS_PROXY=
APPSEC_SMART_SYNC_STORAGE=./appsec-smartsync-storage
APPSEC_USER_EMAIL=user@email.com
APPSEC_DB_PASSWORD=pass
APPSEC_DB_USER=postgres
APPSEC_DB_HOST=appsec-db
APPSEC_POSTGRES_STORAGE=./appsec-postgres-data
## Make sure to have a valid envoy.yaml Envoy configuration file present in the path below.
## For deployment of a simple lab testing environment, you can deploy the example configuration provided
## for the vulnerable juice-shop container, see instructions further below.
ENVOY_CONFIG=./envoy-config/envoy.yaml
## The following two parameters are only relevant if you made a custom configuration for
## the amount of Envoy worker threads using the optional ENVOY_CONCURRENCY parameter (see also explanation in docker-compose.yaml),
## these are then required to make sure that the open-appsec attachment will create the right amount of transaction handlers.
## In this case you must set ENVOY_CONCURRENCY_CALC to "custom" and provide the specified amount of Envoy worker
## threads via "ENVOY_CONCURRENCY_NUMBER".
## Possible values for ENVOY_CONCURRENCY_CALC: "numOfCores" (default), "custom" (allows to set the configured Envoy worker
## thread amount using the ENVOY_CONCURRENCY_NUMBER parameter)
ENVOY_CONCURRENCY_CALC=numOfCores
ENVOY_CONCURRENCY_NUMBER=""
## To connect your deployment to central open-appsec WebUI provide the token for a profile
## which you created in open-appsec WebUI at https://my.openappsec.io
## Example: APPSEC_AGENT_TOKEN=111-22222-111
APPSEC_AGENT_TOKEN=
## Important: When not providing token for connection to central WebUI:
## Make sure to add the value "standalone" to the COMPOSE_PROFILES value, this will enable
## sharing of learning between processes and allow you to perform tuning locally on CLI
COMPOSE_PROFILES=
## JUICE SHOP DEMO CONTAINER:
## In order to deploy the optional, additional, vulnerable juiceshop container (for demo and testing purposes only!):
## Add the value "juiceshop" to the COMPOSE_PROFILES value above.
## Make sure to also adjust the envoy.yaml file in ENVOY_CONFIG path
## to add a routing configuration for forwarding external traffic on e.g. port 80 to the juiceshop-backend container
## you can use the example file available here:
## https://raw.githubusercontent.com/openappsec/openappsec/examples/juiceshop/envoy/envoy.yaml
## place the file above in ENVOY_CONFIG path
## note that juiceshop container listens on HTTP port 3000 by default
## Note that COMPOSE_PROFILES can also receive multiple values, e.g. as shown here:
## COMPOSE_PROFILES=standalone,juiceshop
If you created a deployment profile in the WebUI and copied the Token from it:
Edit the .env
file and add your token to the key APPSEC_AGENT_TOKEN
.
If you did not create a deployment profile in the WebUI and do not want to connect your deployment to central WebUI (SaaS) at all:
Set the value standalone
for the key COMPOSE_PROFILES
which will activate the deployment of additional containers which are required only when not connected to the WebUI at all (resulting in standalone, locally, declaratively managed deployment).
Replace user@email.com
in the .env file with your own email. (More details below.)
When providing your own envoy.yaml configuration file, make sure to add the required configuration to load the open-appsec attachment filter! Follow these instructions: Load the Attachment in Proxy Configuration
.env
file allowing further customization of the deployment:APPSEC_AGENT_TOKEN: For connecting your open-appsec deployment to central WebUI set APPSEC_AGENT_TOKEN to your own deployment profile token as copied from profile settings in the open-appsec central WebUI (see section Prerequisites above).
COMPOSE_PROFILES: Possible values you can set for this key: (you can set multiple values, separated by comma)
standalone
: This will activate the deployment of additional containers which are required only when you are not connected to the WebUI at all, resulting in standalone, locally, declaratively managed deployment.
Only activate the standalone
profile in case you did not set a WebUI deployment profile token as value for the APPSEC_AGENT_TOKEN key (see above)!
juiceshop
: This will deploy an additional, vulnerable juiceshop-backend container that can be used for demo and testing purposes.
Do not activate the juiceshop profile in production environments as the juiceshop container is intentionally highly vulnerable and meant for testing in lab environments only!
USER_EMAIL: (Optional) Associate your email address with your specific deployment by replacing user@email.com
with your own email address.
This allows the open-appsec team to provide you easy assistance in case of any issues you might have with your specific deployment in the future and also to provide you information proactively regarding open-appsec in general or regarding your specific deployment. This is an optional parameter and can be removed. If we send automatic emails there will also be an opt-out option included for receiving similar communication in the future.
APPSEC_HTTPS_PROXY: (Optional) Configure an HTTP(S) proxy server to be used by the agent.
APPSEC_AUTO_POLICY_LOAD: (Optional) When set to true
, allows you to set the open-appsec agent to automatically apply any new changes in the local_policy.yaml file without having to restart the agent container or applying the changes with open-appsec-ctl -ap
(note that this can take up to 30 seconds). This is useful especially in DevOps scenarios with continuous deployment scenarios.
APPSEC_VERSION: Allows you to specify a specific version for deployment instead of using the default latest
version for the containers provided by open-appsec (not relevant for postgres container).
Additional configuration available specifically for this integration type:
ENVOY_CONFIG: Set the directory on the docker host used for the Envoy configuration file mount to the Envoy file path /envoy.yaml
. Make sure to have a valid envoy.yaml configuration file for Envoy in the mounted file path.
For testing purposes in a lab environment you can activate the deployment of the vulnerable juiceshop-backend container via COMPOSE_PROFILES
key (see above) and then deploy the available configuration example for exposing it via the proxy, which is provided by the open-appsec team (download link is provided in the .env
file).
When providing your own envoy.yaml configuration file, make sure to add the required configuration to load the open-appsec attachment filter! Follow these instructions: Load the Attachment in Proxy Configuration
ENVOY_CONCURRENCY: Allows setting the desired amount of Envoy worker processes. I order to use this parameter, specify this in the .env
file and also adjust the "command" line for the appsec-envoy container in the docker-compose.yaml
file (see additional comments in that file).
Make sure to also adjust the following two parameters ENVOY_CONCURRENCY_CALC
and ENVOY_CONCURRENCY_NUMBER
accordingly if you adjusted ENVOY_CONCURRENCY
.
ENVOY_CONCURRENCY_CALC: Only relevant if you made a custom configuration for the amount of Envoy worker threads using the optional ENVOY_CONCURRENCY parameter (see also explanation in docker-compose.yaml). In this case you must set ENVOY_CONCURRENCY_CALC=custom
and then also provide the specified amount of Envoy worker threads in the ENVOY_CONCURRENCY_NUMBER
parameter.
This will make sure that the open-appsec attachment will create the right amount of transaction handlers.
Possible values for ENVOY_CONCURRENCY_CALC
: "numOfCores" (default), "custom"
ENVOY_CONCURRENCY_NUMBER: Only relevant if you made a custom configuration for the amount of Envoy worker threads using the optional ENVOY_CONCURRENCY parameter (see also explanation in docker-compose.yaml).
See explanation for ENVOY_CONCURRENCY_CALC
for more details.
You find some additional advanced configuration options described within the docker-compose.yaml
file as comments.
If you decided to locally, declaratively manage open-appsec with local_policy.yaml
file:
Download the initial declarative configuration file for open-appsec into new subfolder ./appsec-localconfig
:
mkdir ./appsec-localconfig
wget https://raw.githubusercontent.com/openappsec/openappsec/main/config/linux/v1beta1/prevent/local_policy.yaml -O ./appsec-localconfig/local_policy.yaml
Perform the deployment
docker-compose up -d
Verify that all containers are up and running by verifying their status in docker ps output. Note that the amount of container will vary based between deployments with and without connection to central WebUI.
docker ps
You will see output similar to the below:
Congratulations, you successfully deployed open-appsec WAF!
For Production usage we recommend to switch from using the Basic to the more accurate Advanced Machine Learning model, as described here:
If you connected to central WebUI AND configured your deployment profile in the WebUI to "This management" mode for centrally managing open-appsec configuration: Create one or more assets in the WebUI which represent web applications and/or Web APIs which you want to be protected by open-appsec WAF and allows you to adjust the open-appsec configuration specifically for each of them.
Make sure to link your assets to the specific WebUI Profile which you created earlier (General -> Profiles) and adjust the Threat Prevention mode to Detect-Learn or Prevent (Threat Prevention -> Mode), the steps are described here: Protect Additional Assets
Don't forget to Enforce policy in the WebUI after you did any changes for those changes to become effective!
Don't forget to apply the policy using open-appsec-ctl -ap
in the open-appsec-agent container or by setting APPSEC_AUTO_POLICY_LOAD
in the .env
file to true
for automatic application of any configuration changes done in the local_policy.yaml
file for the changes to become effective!
juiceshop
: This will deploy an additional, vulnerable juiceshop-backend container that can be used for demo and testing purposes.
In the .env file you also find a download link for the proxy-specific configuration allowing you to access the juiceshop backend via the proxy. More info on the OWASP juiceshop project:
This example configuration file is already set to mode: prevent-learn
so that open-appsec will prevent attacks right from the start.
Here's the path for an alternative local_policy.yaml file set to detect-learn mode.
(or simply adjust the setting in the mode
setting in the earlier local_policy.yaml file to detect-learn
)
In production environments it's always recommended to start in detect-learn
mode to allow open-appsec to achieve a certain learning level based on traffic observed before moving to prevent-learn
for better detection accuracy and strongly reduced false positives.
Read more about this here:
Track Learning and Move From Learn/Detect to Prevent
You will see output similar to the below. Note that the amount of container will vary based between deployments with and without connection to central WebUI.
If you decided to locally, declaratively manage open-appsec (with or without connection to central WebUI in "Declarative configuration" mode):
Follow the steps described here to configure your open-appsec deployment using the local_policy.yaml
file:
Configuration Using Local Policy File (Docker)
In case you connected your locally managed deployment also to the central WebUI in "Declarative Configuration" mode, you can check security logs and view agent status and configuration also in the central WebUI at .