DEV Community: Sören Metje

How to Deploy Dolibarr on Kubernetes - ERP & CRM System

Sören Metje — Mon, 11 Sep 2023 11:03:59 +0000

Ever wondered how to create invoices without relying on paid services or abusing Microsoft Excel? Dolibarr is a software that provides functionality to create invoices and offers, as well as to manage corresponding resources such as customers, partners, products, service, projects, payments, etc. It is free and open-source. After setup, You can access your own Dolibarr instance via web browser. Officially, Dolibarr is referred as an ERP (Enterprise Resource Planning) and CRM (Customer Relationship Management) system. From my experience, it is overall the best choice among open-source systems. Other candidates are Odoo, Metafresh, Kivitendo, and Apache OFBiz.

This article shows how to set up Dolibarr in your Kubernetes cluster. This way you can benefit from Kubernetes advantages such as high availability and automatic volume backups (if enabled). Although, this might be overkill for some uses cases. As a bonus, a reference to a simple setup using Docker compose is also included.

Try out a Dolibarr demo at https://demo.dolibarr.org

Prerequisites

Kubernetes cluster is set up and ready
Subdomain e.g. dolibarr.example.com points to your Kubernetes cluster
Kubernetes cluster has a ClusterIssuer named lets-encrypt set up and ready (you can adjust this setup if named differently)

Deployment @ Kubernetes

To deploy Dolibarr on your Kubernetes cluster, multiple Kubernetes objects are needed. The GitHub repository https://github.com/soerenmetje/kubernetes-dolibarr contains Kubernetes template files (*.yaml) and detailed setup instructions. In summary, following steps are necessary:

Create a new namespace
Modify the template files
Apply the template files to create the Kubernetes objects
Wait
Check if Dolibarr instance is reachable

If you want to restrict the access to certain IPs or IP ranges, further configuration steps are included in the repository. Additionally, the upgrading process and advanced configuration of Dolibarr, as well as known issues and troubleshooting are covered.

Architecture

In the end, we will end up with following Kubernetes objects:

In the webserver pod, Tuxgasys' Dolibarr Docker image is used. Luckily, this image handles the installation process of Dolibarr automatically on the first start. The db pod runs a mariadb container. The persistent volumes dolibarr-custom, dolibarr-documents, and db-data ensure that configurations, generated PDF files, and the database content is persistently stored. The dolibarr-ingress ingress allows accessing Dolibarr via https using a user-defined subdomain.

Bonus: Deployment @ Docker

In the GitHub repository of Tuxgasys' Dolibarr Docker image a Docker compose deployment is included that integrates traefik as a reverse proxy.

Sources

Stripe Search Query Injections and How to Prevent Them

Sören Metje — Wed, 24 May 2023 11:40:39 +0000

If you directly use user input in a Stripe search query, it is vulnerable to injections. Attackers can exploit this to gain read access to all records of your Stripe resource. The principle is basically the same as in SQL injections. In this article, I propose a fix.

Example

// NodeJS
const stripe = require("stripe")(process.env.STRIPE_SECRET_KEY)

const userInput = "124' OR created>0 OR status:'active" // Injection

let subscriptions = await stripe.subscriptions.search({
    query: `metadata['myField']: '${userInput}'`
})
console.log(subscriptions) // all subscriptions ever

Background

I was developing a backend that integrates Stripe to manage customers and to process subscriptions. In one use case, it should search for user input in the metadata of Stripe subscriptions.
When I looked up the documentation about how to use the search functionality I came across the Search Query Language. It looked like users could easily inject their own additional query clauses. After a simple check: Yes, e.g. for the user input "124' OR status:'active" all active subscriptions are returned as well.

I searched for escape and injection in Stripe documentation and asked Google and ChatGPT - no results.
The Stripe support informed me that there is currently no functionality for this type of validation in the Stripe NodeJS library or API. This is something developers would have to build on their own.
As a developer, I would expect to find this statement in the documentation.

Is this a problem?
A quick search on GitHub for the usage of Stripe search query showed:
4 out of 6 projects I looked at do not implement any input escape or input validation functionality. Therefore, all these projects are potentially vulnerable.

Solution

I wrote a small NodeJS library stripe-escape-input that does the job.

npm i stripe-escape-input

const escapeInput = require("stripe-escape-input")
const stripe = require("stripe")(process.env.STRIPE_SECRET_KEY)

const userInput = "124' OR created>0 OR status:'active" // Injection

let subscriptions = await stripe.subscriptions.search({
    query: `metadata['myField']: '${escapeInput(userInput)}'`
})
console.log(subscriptions) // 0 subscriptions

To prevent injections, we need to escape the user input before using it in a Stripe search query. What exactly has to be considered tells us the Stripe query language documentation. Let's hope it is complete.
Based on that, it comes down to string replacement of single quotes ', double quotes ", and backslashes \, so an attacker can not end the value part and add additional query clauses.

Final Thoughts

Is this a good solution? No. As an external developer, I can only implement what is documented by Stripe. There might exist undocumented behavior that could lead to new vulnerabilities. The best approach would be for Stripe to provide this functionality since they know all the implementation details of their search queries. Until then, this is the best we can achieve.

References

Debugging Kubernetes Applications - A Swiss Army Knife Pod

Sören Metje — Sat, 15 Apr 2023 21:05:37 +0000

To debug Kubernetes applications, e.g. if pods can reach a service, an interactive container shell including all essential tools is great - a Swiss army knife so to speak. Unfortunately, in popular base images such as Ubuntu, Debian, CentOS, and Busybox essential debugging tools are not included due to image size reduction and security. While this is great in production environments, it is counterproductive for debugging. Here, we presented an approach based on the extended Ubuntu image leodotcloud/swiss-army-knife created by leodotcloud.

Usage

Create Debugging-Pod

Spin up the pod:

kubectl create -n mynamespace -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: swiss-army-knife
  labels:
    app: swiss-army-knife
spec:
  containers:
  - name: swiss-army-knife
    image: leodotcloud/swiss-army-knife:latest
    command: ["/bin/sleep", "3650d"]
    imagePullPolicy: IfNotPresent
  restartPolicy: Always
EOF

Get Interactive Shell

Get access to the container command line and debug your stuff:

kubectl exec -n mynamespace swiss-army-knife  -it -- /bin/bash

As an example the following command checks whether the port 3306 (MySQL) is accessible on 10.152.183.115:

netcat -v -z -w 4 10.152.183.115 3306

Remove Debugging-Pod

After debugging, you can delete the pod:

kubectl delete pod -n mynamespace swiss-army-knife

Tools and Packages

Following tools and packages are included. An up-to-date list is available in the Dockerfile.

arping
arptables
bridge-utils
ca-certificates
conntrack
curl
dnsutils
ethtool
iperf
iperf3
iproute2
ipsec-tools
ipset
iptables
iputils-ping
jq
kmod
ldap-utils
less
libpcap-dev
man
manpages-posix
mtr
net-tools
netcat
netcat-openbsd
openssl
openssh-client
psmisc
socat
tcpdump
telnet
tmux
traceroute
tcptraceroute
tree
ngrep
vim
wget

Sources

How to Secure a Docker Host Using Firewalld

Sören Metje — Thu, 23 Feb 2023 23:41:45 +0000

If you are using a firewall like ufw or firewalld and docker you may encounter the problem that docker bypasses the firewall rules.

Goal

The firewall rules should count for whole host system - so including Docker containers with port mappings
A Docker container should be accessible from the internet if and only if the host port used in Docker container port mapping is allowed in the firewall
The approach should not break container networking

Existing Approaches

I found following approaches that try to fix the problem. However, each approach introduced another problem:

Just do not use docker. Podman for example obeys firewall rules by default. Problem: Some can not or may not want to switch to a different container runtime, but I generally recommend checking if this is an option for you. This article includes a comparison.
Use external firewall like security groups in Openstack instead of ufw or firewalld. Problem: Not available in my case.
Just do not map ports in docker. Problem: may introduce security risk because of no single source of truth for exposed host ports.
Disabling iptables for docker. Problem: Containers can not access internet.
Configuring the firewall to ignore port mappings. Problem: The port inside the container have to be allowed in the host firewall. If multiple containers use same port and only one should be allowed we have to additionally specify container IP or service name. In summary: Counterintuitive, complex and error-prone.

Approach

Idea: Disable iptables for docker and configure firewalld to allow container networking. It is based on this Medium article by Erfan Sahafnejad and several posts. I tested it with Ubuntu 22.04.2 LTS but the concept should also work on other Linux.

Security Implications

It is important to notice, that this approach can have security implications depending on the setup, e.g., as described Keval Kapdee's post. In his setup, he operated a mail server in a docker container with a similar configuration as discussed in this article. Due to the configured masquarading of packets, from the mailserver perspective, all packets originate from the IP address 172.22.1.1, which is listed as a trusted address in Postfix by default. Therefore, Postfix relayed all requests from every internet IP address as these were seen as originating from a trusted address. In summary, this approach is not suited for use cases, which use original internet IP addresses, e.g., for access control.

Overall, especially in production setups, I recommend using other approaches such as Podman instead of the approach discussed in this article.

Preparation

If you added any configuration to iptables regarding docker before, remove it first.

If ufw is installed and active, disable it:

ufw disable

Install and activate firewalld:

apt update && apt install firewalld -y
systemctl enable --now firewalld

# Confirm that the service is running
firewall-cmd --state

Compared to ufw, firewalld is more powerful - it provides features that we need for upcoming firewall configurations. However, it also just a convenient frontend for iptables. Learn more about firewalld here: https://docs.rockylinux.org/guides/security/firewalld-beginners/

Disable iptables for Docker

Disable iptables for docker in /etc/docker/daemon.json so it should look like follows:

{
"iptables": false
}

If /etc/docker/daemon.json does not exist, create the file first.

Restart docker:

systemctl restart docker

Already at this point, only container ports that are allowed in firewall should be reachable from the internet. However, as a side effect of disabling iptables in docker, we broke container internet access: From the inside of containers we can not access the internet anymore.

docker run --rm busybox ping -c4 8.8.8.8
# PING 8.8.8.8 (8.8.8.8): 56 data bytes
#
# --- 8.8.8.8 ping statistics ---
# 4 packets transmitted, 0 packets received, 100% packet loss

Configure firewalld

At next, we configure firewalld to enable docker container networking.

Add Masquerading to the zone which leads out to the Internet, typically public:

# Masquerading allows for docker ingress and egress (this is the juicy bit)
firewall-cmd --zone=public --add-masquerade --permanent
# Reload firewall to apply permanent rules
firewall-cmd --reload

Sources: https://serverfault.com/a/987687 and https://serverfault.com/a/1046550

Additionally, in order to enable docker containers accessing host ports, add docker interface to the trusted zone:

# Show interfaces to find out docker interface name
ip link show

# Assumes docker interface is docker0
firewall-cmd --permanent --zone=trusted --add-interface=docker0
firewall-cmd --reload
systemctl restart docker

Sources: https://unix.stackexchange.com/a/225845 and https://unix.stackexchange.com/a/333356

So far, docker containers that are not attached to a docker network can access the internet. But containers that are attached can still not. This is often the case when using docker compose.

If we try to ping Google DNS server this is the result:

docker run --rm busybox ping -c4 8.8.8.8
# PING 8.8.8.8 (8.8.8.8): 56 data bytes
# 64 bytes from 8.8.8.8: seq=0 ttl=58 time=3.699 ms
# 64 bytes from 8.8.8.8: seq=1 ttl=58 time=3.588 ms
# 64 bytes from 8.8.8.8: seq=2 ttl=58 time=3.587 ms
# 64 bytes from 8.8.8.8: seq=3 ttl=58 time=3.518 ms
#
# --- 8.8.8.8 ping statistics ---
# 4 packets transmitted, 4 packets received, 0% packet loss
# round-trip min/avg/max = 3.518/3.598/3.699 ms


# Create docker network for testing purpose (can be deleted later)
docker network create --driver bridge mynet

docker run --rm --net mynet busybox ping -c4 8.8.8.8
# PING 8.8.8.8 (8.8.8.8): 56 data bytes
#
# --- 8.8.8.8 ping statistics ---
# 4 packets transmitted, 0 packets received, 100% packet loss

To fix this, add your network interface to public zone:

# Show public ip
curl -4 ip.gwdg.de
# Show interfaces to find out network interface name with your public IP
ip addr

# Assumes network interface with your public IP is eth0
# (ens18 is also a name I came accross)
firewall-cmd --permanent --zone=public --add-interface=eth0
firewall-cmd --reload

Networking should work properly now and therefore containers should be able to access the internet.

If we now try to ping Google DNS server again, it works as expected:

docker run --rm busybox ping -c4 8.8.8.8
# PING 8.8.8.8 (8.8.8.8): 56 data bytes
# 64 bytes from 8.8.8.8: seq=0 ttl=58 time=3.641 ms
# 64 bytes from 8.8.8.8: seq=1 ttl=58 time=3.565 ms
# 64 bytes from 8.8.8.8: seq=2 ttl=58 time=3.605 ms
# 64 bytes from 8.8.8.8: seq=3 ttl=58 time=3.546 ms
#
# --- 8.8.8.8 ping statistics ---
# 4 packets transmitted, 4 packets received, 0% packet loss
# round-trip min/avg/max = 3.546/3.589/3.641 ms

docker run --rm --net mynet busybox ping -c4 8.8.8.8
# PING 8.8.8.8 (8.8.8.8): 56 data bytes
# 64 bytes from 8.8.8.8: seq=0 ttl=58 time=3.671 ms
# 64 bytes from 8.8.8.8: seq=1 ttl=58 time=3.644 ms
# 64 bytes from 8.8.8.8: seq=2 ttl=58 time=3.561 ms
# 64 bytes from 8.8.8.8: seq=3 ttl=58 time=3.508 ms
#
# --- 8.8.8.8 ping statistics ---
# 4 packets transmitted, 4 packets received, 0% packet loss
# round-trip min/avg/max = 3.508/3.596/3.671 ms

Open Firewall Ports

In the end, open the desired ports for your service to allow incoming traffic, e.g. on port 8080:

firewall-cmd --permanent --zone=public --add-port=8080/tcp
# Reload firewall to apply permanent rules
firewall-cmd --reload

Extra: Testing

It is important to run tests to ensure the whole setup is working properly. Although the actual tests depend on your setup, here are some statements that may be important to verify:

Container running on allowed port can be accessed from internet
Container running on not allowed port can not be accessed from internet
Container can access internet
Container with new docker network can access internet
Container can access service running on host system port
Container can access other container inside same docker network

To start a webserver on 8080 you can run:

docker run --restart unless-stopped -p 8080:80 -d nginx

To curl a service running on host system port from inside of a container you can run:

# Show docker interface ip address
ip addr
# ...
# 3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
#    link/ether 02:42:37:6b:6e:2a brd ff:ff:ff:ff:ff:ff
#    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
#       valid_lft forever preferred_lft forever
# ...

# Assumes docker interface ip is 172.17.0.1
# and service runs on port 80
docker run --rm curlimages/curl -v http://172.17.0.1:80/

DEV Community: Sören Metje

How to Deploy Dolibarr on Kubernetes - ERP & CRM System

Prerequisites

Deployment @ Kubernetes

Architecture

Bonus: Deployment @ Docker

Sources

Stripe Search Query Injections and How to Prevent Them

Example

Background

Solution

Final Thoughts

References

Debugging Kubernetes Applications - A Swiss Army Knife Pod

Usage

Create Debugging-Pod

Get Interactive Shell

Remove Debugging-Pod

Tools and Packages

Sources

How to Secure a Docker Host Using Firewalld

Goal

Existing Approaches

Approach

Security Implications

Preparation

Disable iptables for Docker

Configure firewalld

Open Firewall Ports

Extra: Testing

Further Reading

Sources