-
-
Notifications
You must be signed in to change notification settings - Fork 583
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add HTTPS support #1520
Comments
The simplest way would be to put NGINX in from the the API Server ad Frontend and let NGINX handle TLS. This is what most organizations do today. Future versions of Dependency-Track will ship with more and more smaller components (e.g. CycloneDX BOM Repo Server, etc), managing certificates on every container will be problematic. |
I'm working with apache and fight CORS which I just submitted a bug for. I'm not apposed to switching to NGINX to proxy it. Would you happen to have a known working configuration? I can't seem to get the right combination. I have many other webapp servers. The configuration for DependencyTrack seems to be working a little different. |
@croniserb maybe this will help. Create config for both components frontend and API server. Then also configure Dependency-Track to use the HTTPS endpoint API from the frontend... I set this up using an AWS ELB and it took me about 1 hour to properly configure it... because the frontend needed to be configured to use the https endpoint. It would probably be a good idea to have a wiki page or something with some info on a couple of scenarios adding HTTPS. Its not complicated, its just a little bit hidden in the config and you need to read the manual, just the docker compose up instruction is a bit misleading. |
@webmutation Interesting. I'm using an AWS EC2 instance. If I set
|
If you are using an EC2 instance, you can create an ELB or use Apache... its all about routing the requests to the right application. In this ELB type Application you can create two HTTPS Listener 443 for Frontend and 8443 or whatever other port to use for the API. Then you will have two Target Group type instance pointing to the same instance where you have DT installed. In one Target group you point to 8080 (default frontend port) and on the other Target Group you point to 8081 (default API server port) If you want to just use Apache you can also do that, it will be similar create two virtual host application one running on port 443 the other on port 8443 or 444 and put in place TLS termination. You can use Letsencrypt for the SSL certs. Since the UI communicated with the backend you can also use local traffic with rewrite rules. etc... but its better to have TLS all over so you dont have mixed http/https content warnings... There are many ways to get this to work. In my case I use ELB because its simpler for me with ACM. The most important take-away is that with the new distribution model in 4.x you have to treat them as separate apps that are connected via the config file. Hope this helps... I will try to contribute a guide to the Docs for a couple of use cases. So I fully agree with @stevespringett TLS termination should be the responsibility of the LB or RP. |
@webmutation I think that was the cookie crumb I needed. I think I was creating a loop by having API_BASE_URL=https://system.domain.net:8081 still defined in docker-compose.yml. By commenting that out, I think I'm running. The webfrontend is proxied on 8080 for /. /api is proxied on 8081. Both are on 443 with Let's Encrypt. I am successful at logging. I do see this error that has me concerned that I don't have something configured just right yet. |
The last error appears to have been due to browsers caching. I am not seeing that error now. |
The docker frontend of DependencyTrack already ships with NGINX and you could use it as a reverse proxy for the backend part. At least this is what I've done. ` Compose.ymlModify the docker-compose.yml frontend part, so that a local default.conf for NGINX is mapped into the container, the API_BASE_URL is set correctly and the new API ports are addded to the list.
NGINX Reverse Proxy Setup
` |
Hello @bytew0lf, I've been struggling to set up the certificate I've been delivered for my instance of dependency-track and your configuration feels like the closest I've gotten to understanding any of it. I just have a couple of questions about what you've written:
Thanks. |
Hi @GHSebamo, You can leave the first server section of the default.conf alone, this is just for redirecting every request from http to https. The second server section is for the frontend there you only have to change the server name to the FQDN of your server and maybe the names of the certificate files. The third server section is the reverse proxy for the REST API, there you have to change the server name to the FQDN of your server and the variables proxy_pass and proxy_redirect so that dtrack.example.local is exchanged with your server FQDN. The dollar sign variables can be left as is. Hope that helps. |
Quick FYI for anyone else following the instructions provided by @bytew0lf (thank you btw!)
Search terms to make sure this can be found:
|
@alexbartok I was reading the topic and you just commented, thanks |
Following the instructions that @bytew0lf passed, I managed to make HTTPS work in my DT, I would like to thank @bytew0lf and @alexbartok for the help given to the DT community. |
@bytew0lf I have a self signed certificate and its giving me https://10.33.0.50:8443/api/version net::ERR_CERT_COMMON_NAME_INVALID. How can i handle it any help is appreciated. |
Hi @vishal-gurnaney, Linode has a good article about multiple SANs in one certificate: https://www.linode.com/docs/guides/using-openssls-subjectaltname-with-multiple-site-domains/ Hope that helps you out. |
Thanks for the reply @bytew0lf. #openssl x509 -text -noout -in C:\Setups\DependencyTrack\Certificates\tool.dependency.track.crt | grep DNS
Am i missing something here ? |
You'll have to specify the IP as well in the SAN, not only the the DNS if you access the system with the IP, like you showed in your previous post. That's what worked for me in my setup. |
@bytew0lf yes I modified it specified both IP and DNS it worked for me. |
@bytew0lf i am trying to build CI\CD pipeline using the API i am trying to upload the BOM file. |
Hi @vishal-gurnaney , @bytew0lf and @viniciusnavarro Nignx Config server {
}
} Docker Compose Consol Error API Server Error |
@bytew0lf I am facing the CORS issue, I followed all steps. |
I have resolved CORS issue by adding additional parameters:
However 504 error is still there unable to access xxx:8443/api/*. |
@stevespringett agree, but why don't DT use this "simple" approach as default but rather expose API server via HTTP? As you said , this is what most organizations do today, and most of them hide API server behind Nginx reverse proxy. DT is a cybersecurity focused tool, and I believe most people agree using Https rather than Http for better security. Just don't get it why DT still stick on Http? |
@bytew0lf @alexbartok https works via this when connecting to dtrack-frontend, but dtrack-apiserver still expose port 8081 via http to outside, can we use https instead?
|
Access issue also resolved, that was of misconfigurations of ports at host machine, everything is working now, Thanks @bytew0lf and everyone else who contributed. |
For the record, Gitea's docker installation allows HTTPS through the docker-compose.yml through this syntax which it puts in it's app.ini that nginx reads
|
Hello all, I'm also struggling with deploying dependency-track using https. When I try to start via docker-compose I get an error:
I did the following steps:
The compose file looks something like this: version: '3.7'
volumes:
dependency-track:
services:
dtrack-apiserver:
image: dependencytrack/apiserver
environment:
- ALPINE_DATABASE_MODE=external
- ALPINE_DATABASE_URL=jdbc:[PATH_TO_SERVER]
- ALPINE_DATABASE_DRIVER=com.microsoft.sqlserver.jdbc.SQLServerDriver
- ALPINE_DATABASE_USERNAME=deptrack
- ALPINE_DATABASE_PASSWORD=[SOMETHING]
deploy:
resources:
limits:
memory: 12288m
reservations:
memory: 8192m
restart_policy:
condition: on-failure
ports:
- '8081:8080'
volumes:
- 'dependency-track:/data'
- "/etc/pki/ca-trust/extracted/java/cacerts:/opt/java/openjdk/lib/security/cacerts:ro"
restart: unless-stopped
dtrack-frontend:
image: dependencytrack/frontend
depends_on:
- dtrack-apiserver
environment:
- API_BASE_URL=https://deptrack.company.net:8443
volumes:
- 'dependency-frontend:/data:ro'
#- "/var/lib/docker/volumes/dtrack_dependency-frontend/_data/:/data:ro"
- "/var/lib/docker/volumes/dtrack_dependency-frontend/_data/default.conf:/etc/nginx/conf.d/default.conf"
ports:
- "80:8080"
- "443:9443"
- "8443:8443"
restart: unless-stopped Could somebody please give me a hint? Thanks for help! |
In the section called "volumes" it's missing the volume "dependency-frontend" Would be like this:
|
yuenfaytsang built something that works out of the box:
the docker-compose is pretty much vanilla: version: '3.7'
volumes:
dependency-track:
services:
dtrack-apiserver:
image: dependencytrack/apiserver
deploy:
resources:
limits:
memory: 12288m
reservations:
memory: 8192m
restart_policy:
condition: on-failure
ports:
- '8081:8080'
volumes:
- 'dependency-track:/data'
restart: unless-stopped
dtrack-frontend:
image: dependencytrack/frontend
depends_on:
- dtrack-apiserver
environment:
- API_BASE_URL=https://deptrack.localdomain
ports:
- "8080:8080"
restart: unless-stopped The magic happens in the NGINX configuration: server {
listen 80;
server_name deptrack.localdomain;
### SEND 404 IF HOSTNAME DOES NOT MATCH
if ($host !~ ^(deptrack.localdomain)$ ) { return 404; }
### REDIRECT HTTP TO HTTPS
return 301 https://$host$request_uri/;
}
server {
listen 443 ssl http2;
server_name deptrack.localdomain;
### SEND 404 IF HOSTNAME DOES NOT MATCH
if ($host !~ ^(deptrack.localdomain)$ ) { return 404; }
### TLS CERTIFICATES
ssl_certificate /etc/pki/tls/certs/deptrack.crt;
ssl_certificate_key /etc/pki/tls/private/deptrack.key;
### TLS HARDENING
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA HIGH !RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS";
### DEPENDENCY TRACK FRONTEND
location / {
proxy_pass http://localhost:8080/;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Port $server_port;
proxy_hide_header X-Powered-By;
proxy_hide_header Server;
}
### DEPENDENCY TRACK APISERVER
location /api/ {
proxy_pass http://localhost:8081/;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Port $server_port;
proxy_hide_header X-Powered-By;
proxy_hide_header Server;
}
### PREVENT SERVING HIDDEN FILES
location ~ /\. {
deny all;
return 404;
}
} All that needs to be done is to replace This config uses only Port 443 to the outside of the host. To reach the API use |
Thanks for config! But in my experience it turned out to be more correct to specify
Otherwise, all requests to the api did not work correctly.
|
I also chose the workaround to have an nginx reverse proxy container as middleware to have https access to the platform. If it helps somebody, I used the following config /home/user/dependency-track/docker-compose.yml
/home/user/dependency-track/nginx-config/dtrack-frontend.conf
/home/user/dependency-track/nginx-config/dtrack-apiserver.conf
|
|
maybe will be useful for some one docker-compose.yml
default.conf
|
There's a typo in this |
I see that there are work-arounds to achieve https support. Are there plans to embed it into the docker container? |
Current Behavior:
Currently http only requests to the docker containers are supported.
http://dependencytrack.domain.com:8080
Proposed Behavior:
Add https support for https connections and certificates for Let's Encrypt and other certificate authorities
https://dependencytrack.domain.com:8443 --- https main page
API_BASE_URL=http://thunder.pargovernment.net:8444 --- updated config for https
Proposed changes for the docker-compose.yml
ALPINE_SSL_CERTIFICATE_FILE=/etc/letsencrypt/live/dependencytrack.domain.com/fullchain.pem
ALPINE_SSL_CERTIFICATE_KEY_FILE=/etc/letsencrypt/live/dependencytrack.domain.com/privkey.pem
ALPINE_SSL_CERTIFICAT_CHAIN_FILE=/etc/letsencrypt/live/thunder.pargovernment.net/chain.pem
ALPINE_INCLUDE/etc/letsencrypt/options-ssl-apache.conf
The text was updated successfully, but these errors were encountered: