Дмитрий

fail2ban

Потому что .env подключается вот так

version: "3.5"
services:
  db:
    build:
      context: ./docker
      dockerfile: postgresql.Dockerfile
    env_file:
      - .env
    restart: always
    volumes:
      - postgres:/var/lib/postgresql/data
    ports:
      - "127.0.0.1:5432:5432"
  redis:
    env_file:
      - .env
    restart: always
    image: redis:3.0
    expose:
      - "6379"

UPD:
.env файл обычно (всегда) не ложат в контейнер, скорее наоборот всячески избегают этого,
т.к. в нём хранится чувствительная информация, как правило это различные токены и т.д.
Хранение подобного в репозитории это плохой тон. Но можно хранить какой-нибудь example.env
в качестве образца.

В данном образе .env файл создается автоматически при билде образа и содержит одну единственную строку.
Вот команда которой он создается:
echo 'APP_ENV=docker' > .env

Если вы внимательно посмотрите в README, то увидите что там об этом говорится .
Помимо этого, автор рекомендует монтировать .env файл из вне, либо копировать его в контейнер (что является общепринятой практикой)

В Readme написано:

Database credentials and other sensitive information should not be committed to the repository. Those required settings should be outlined in .env.example

Passing environment variables via Docker can be problematic in production. A phpinfo() call may leak secrets by outputting environment variables. Consider mounting a .env volume or copying it to the container directly.

Честно говоря, не понятно ваше стремление редактировать .env в самом контейнере, вместо того чтобы его пробрасывать внутрь.

Если надо ftp - гуглите "iptables passive ftp"

А лучше мигруйте на sftp.

Если у вас установлен и настроен ingress-контроллер, то примерно так:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: kubernetes-dashboard
  annotations:
    kubernetes.io/ingress.class: nginx
    kubernetes.io/tls-acme: "true"
    ingress.kubernetes.io/ssl-redirect: "true"
    ingress.kubernetes.io/use-port-in-redirects: "true"
  namespace: kube-system
spec:
  tls:
  - hosts:
    - kubedash.example.com
    secretName: kubedash-tls
  rules:
  - host: kubedash.example.com
    http:
      paths:
      - path: /
        backend:
          serviceName: kubernetes-dashboard
          servicePort: <порт_вашего_сервиса>

Если контроллера нет или не планируется, но нода/ы имеют внешний доступный IP, то можно сделать доступным сервис так (и не забыть на файерволе правило настроить для выбранного порта):

kind: Service
apiVersion: v1
metadata:
  labels:
    k8s-app: kubernetes-dashboard
  name: kubernetes-dashboard-nodeport
  namespace: kube-system
spec:
  type: NodePort
  ports:
    - port: 443
      targetPort: 8443
      nodePort: <порт_для_доступна_снаружи>
  selector:
    k8s-app: kubernetes-dashboard

Сразу хочу сказать, что я хорошо ознакомлен с Linux, так что ознакомиться с BlackArch мне будет не очень трудно.

Если бы ты был реально "хорошо ознакомлен", ты бы поставил этот blackarch в песочницу, поигрался бы, нашёл ответы на свои вопросы и возможно по пути отправил бы баг-репорт разработчикам. И не было бы этого вопроса.

не поймите меня неправильно

Вместо того, чтобы заниматься делом ты "познаёшь системы" с "проффесиональным интерфейсом" и строчишь о своих муках выбора вопросы на тостер, я тебя правильно понял?

является ли это руткитом или ложная тревога?

Скачайте сами пакеты установленных версий, которые подозрительные файлы поставляют, и сравните хеши.

Насчёт вход через SSH на рут аккаунт

Файл конфига находится обычно по адресу /etc/ssh/sshd_config, параметр PermitRootLogin должен быть не закомментирован и иметь значение no. Перед изменением стоит помнить, что надо заранее обеспечить доступ по SSH с другой учётки, если нет прямого терминала.

1) ENTRYPOINT заменить на CMD и почитать про разницу
2) Наследоваться от python:3.7, а не от ubuntu
3) Не лепить виртуальную среду в докер образе

Каким способом эффективнее организовать сеть внутри вахтового поселка?

WiFi
Вахтовый поселок вещь временная и вагончики зачастую двигают поэтому тянуть кабель невыгодно, плюс замучаетесь с грозозащитой.
Качество WiF похуже чем у витой пары, но учитывая что это дорожники - эфир будет чистым и сеть будет работать нормально. По цене практически одинаково, но в случае витой пары все затраты заново, а тут один раз потратились и все.

Wi-Fi сквозь них не проходит

На каждый вагончик - WiFi клиент.
MikroTik SXT Lite, Ubiquiti NanoStation Loco и подобные. Размещать на улице чтобы ничего не мешало приему сигнала. Внутрь домика по витой паре, питание по ней же. Внутри либо подключение витой парой либо самый дешевый WiFi роутер.
Для раздачи использовать всепогодные станции вроде Ubiquiti UniFi AP AC Mesh. У микротика тоже есть неплохие модели в этом сегменте.