docker compose for just headscale-admin?

[europacafe]

Hi,
I'm now using a a docker compose file to run both headscale server and headscale-webui.
I usually run headscale-webui with its local IP, because I don't want to expose the UI on the internet.
I want to try your headscale-admin alongside the current headscale-webui without having to touch my current docker compose file.

If I create another docker compose file just for the headscale-admin, could you guide me on what to put in the compose file?
I have tried with below compose, but I only got the settings page (http://localip:8881/admin), and after inputting my headscale server URL (https://headscale.mydomain.com) and a newly generated apikey, it goes nowhere.

version: '3.9'
services:
  headscale-admin:
    image: goodieshq/headscale-admin:latest
    container_name: headscale-admin
    restart: unless-stopped
    networks:
      - headscale_default
    ports:
      - 8881:80
    environment:
      - ENDPOINT=/admin   #default: /admin
networks:
  headscale_default:
    external: true

Thank you.

[europacafe]

The docker-compose is ok. I've just had to set my haproxy to access it with the same https url as the headscale server.

[GoodiesHQ]

That docker compose does look fine.

Just to be clear, this UI is essentially nothing but a fancy wrapper around CURL-like HTTP requests that is presented in a browser. Anything you can do in the web UI can be done with CURL which has no CORS limitations. Technically speaking, as long as your headscale is exposed to the internet (and it almost certainly is, as virtually all instances are), anyone can attempt to make requests to it, with or without access to this or any Web UI. The security of this application and any others like it relies on the fact that your API key is stored in your browser's LocalStorage and is only send to the headscale API. It is not sent to the admin interface at any point. The Caddyfile only serves static HTML files and doesn't handle incoming requests (other than GET /) or any authentication/authorization, it just serves the scaffolding for the UI. Having it exposed is not a security threat. Your API key is what you need to protect.

However, I always recommend this and any HTTP application should be protected behind an SSL certificate to ensure integrity from the server and to prevent attacks such as script injection. That is a legitimate security threat when using an HTTP interface as it could theoretically lead to someone compromising your API key if they were to inject malicious javascript into your browser as your browser downloads the web app.

[europacafe]

Thanks for your clarification.
I notice such nature of the app because each device opening the UI webpage needs its own API key.
For headscale-webui app, it requires only one API key to work very every device; in such case, I've never exposed the UI to internet.

[GoodiesHQ]

Agreed. I ultimately wanted it to be static because I think it maximizes portability and reduces the need for focused security other than SSL certs as mentioned. Ultimately I decided that most people would be dockerizing this along with headscale and as such would likely be using a reverse proxy which can handle SSL certs. Although it does seem like there is a notable percentage of people running it on bare metal. More than I anticipated.