Q: Using Postgres V16 in docker-compose instead of V12

[4d62]

I noticed in the docker-compose.yml file that the Postgres image is set to version 12. Is there any specific reason why a newer version isn't recommended in the Docker Compose file? Considering that version 12 will reach its end of life in six months, would it be wise to create the database on version 16 or attempt to upgrade the current one? Also, how does this decision impact security?

[BeryJu]

The main reason why we haven't updated the postgres tag is because the upgrade procedure for postgres is a lot more manual than it is for redis or mysql. There aren't any new postgres features required by authentik either, but we test in CI with 12, 15 and 16. We will probably upgrade in the future, after we have some docs on how to upgrade too

[4d62]

Thank you for your explanation. A few days ago, I attempted to update the database following several online guides, but it turned out to be a disaster. Fortunately, I had taken a backup. The issues I'm concerned about (perhaps not without good reason) are performance improvements and possibly patched security issues.

[BeryJu]

I dont think there's too much to gain there, although I don't have any numbers for performance, but for security especially since postgres isn't exposed to anything there shouldn't be any issues

[4d62]

According to this article by EntrepriseDB, there is a 10% performance increase between Postgres 12 and 15. I could not find any statistics for V16. But for what it's worth, it is probably best to wait for EOL. Updating from a Docker container is way trickier than on the VM

[4d62]

Gonna write docs for the upgrade and open a pull request as I have made the update myself with basically no issues

[appiekap653]

I dont think there's too much to gain there, although I don't have any numbers for performance, but for security especially since postgres isn't exposed to anything there shouldn't be any issues

I don't believe this is exactly true when using the default docker-compose file from: https://goauthentik.io/docker-compose.yml

There is no use of separated networks in the compose file where the network for the Postgres container is set to: internal: true like this:

networks:
  external:
    name: external
    driver: bridge
    ipam:
      config:
        - subnet: 172.30.0.0/24
          gateway: 172.30.0.1

  internal:
    name: internal
    driver: bridge
    internal: true
    ipam:
      config:
        - subnet: 172.31.0.0/24
          gateway: 172.31.0.1

So the Postgres container will have access to the outside internet with the default docker-compose file and can be vulnerable to attacks.

[4d62]

@appiekap653 So basically, the best solution would be 2 networks? authentik-external on the worker and server with authentik-internal all? I might be mistaken but since Postgres runs on a network it would not be accessible via the VM IP and it would be basically impossible to access it with the internal ip, how could an attacker do anything?

[appiekap653]

You only need one other container on that and network where an attacker can take over the container, and he can launch his attacks to the rest of the containers.

I use two networks, with one of them set to internal, just to be sure.

I read somewhere that docker was automatically doing something to iptables for all containers in a bridge network, which made it insecure when not using internal=true.

I don't know the actual in's and outs, but can never be sure enough when it comes to security.

Look at the custom network part: https://spin.atomicobject.com/defined-docker-networks/

[4d62]

Oh that's good to know. Thanks for sharing