OHDSI Home | Forums | Wiki | Github

Broadsea: Local and Highly Secured Deployment of Broadsea

Implementers
#1

Problem Statement

Docker is often not able to be deployed by default in some environments. IT departments may have default environment settings that do not allow for Docker. In some settings, this may involve a lengthy process of paperwork and approvals to change, which increases the barriers to using Broadsea. In other settings, the deployment may not be feasible at all due to policy.

Types of Problems

Security: The permissions provided to a user may not allow for some of the aspects of Docker or the technologies in docker-compose. However, it would be possible using different tooling that the same functionality could be possible under default user permissions.

Firewalls: The ports necessary may not be able to be opened, even locally, depending on the security settings. This may impact the Broadsea database deployment and WebAPI in particular.

Virtualization Performance/Security: The secure environment is hosted on a server, which is frequently a virtualization itself. For both security and performance reasons IT Admins may not approve of virtualization on top of virtualization.

Initial Ideas

  • Ansible to orchestrate local installations
  • Integrating an option to use DuckDB over Postgres as the Broadsea database

Github Issue

1 Like
#2

@hspence Here are some additional ideas you could investigate which may enable some secure sites to run the Broadsea container images:

  • Podman - doesn’t run as root, and no Docker service running on server:
    https://podman.io/

  • Kubernetes - may be a good option if a site is already using it for other applications

  • AWS Elastic Container Service (ECS) or other cloud container service equivalent

This AWS Whitepaper - Architecting for HIPAA Security and Compliance on AWS may be a useful reference for secure cloud services approach:
https://docs.aws.amazon.com/pdfs/whitepapers/latest/architecting-hipaa-security-and-compliance-on-aws/architecting-hipaa-security-and-compliance-on-aws.pdf#architecting-hipaa-security-and-compliance-on-aws

Note. A local site install of PostgreSQL or cloud database service like AWS RDS is recommended for Broadsea production use instead of the demo broadsea-atladb container image.

There is also an OHDSI-in-a-box virtual server image that doesn’t use Docker here (Windows or Linux OS):
https://github.com/OHDSI/OHDSI-in-a-Box

#3

@hspence - well stated. With Broadsea, our goal is to try to get these tools into more sites as smoothly as possible.

One item I’ll raise is about Firewalls; because we’re using Traefik, you really only need port 80/443 open for the host server. There are other ports used within the Docker network (e.g. 8080 for WebAPI, 5432 for Postgres, 8787 for RStudio, 8983 for Solr), but they do not need to be opened for clients accessing the host server.

I think also performance is not a major issue with this stack. The only container that uses any significant compute would be HADES on RStudio, but that is not intended for a production-level deployment, just for testing and smaller jobs.

Security-wise, we could stand to improve it by using Docker secrets over env variables. And require more authorization patterns for services like Solr.

@admin - Podman seems interesting. It removes the need for super user access. The big question is with its functionality for compose compared to Docker’s; can we use the same approaches to profiles and build contexts?

#4

Podman appears to support compose, but profiles support is only in the podman compose development branch, not yet a stable release.

Also: there’s not a clean way to have podman provision ports 80 and 443 as it runs in rootless mode. This would need to be settled upfront by the server admin.

t