digihunch/orthweb

Orthanc on AWS with Infrastructure as Code

Orthweb - Orthanc on AWS

Overview

Orthweb helps imaging IT administrators operationalize Orthanc on AWS. It proposes a self-contained architecture, and accelerates the deployment of it. Bring your own AWS account, and Orthweb help you set up Orthanc server in half an hour, ready to serve HTTP and DICOM traffic.

The Orthweb project proposes an architecture that involves numerous underlying cloud resources in AWS (e.g. VPC, subnets, Secret Manager, RDS, S3) with security, automation and high availability in consideration. Orthweb orchestrate these resources with Infrastructure as Code in Terraform.

On top of the infrastructre, Orthweb also automatically configures the hosting of Orthanc application with Docker, using the Orthanc image released by Osimis. For those who need to host Orthanc on Kubernetes, check out Orthweb's sister project Korthweb.

The Orthweb documentation includes a step-by-step guide for deployment and more details about the architecture.

orthweb's Issues

build s3 plugin

Better way to SSH to an instance

Currently, Orthweb configures RSA key pair for user to SSH to instance. This step is a little involving:

1. To SSH in, user has to create a key pair. That turns out to be a distractive step in user's experience.
2. A separate public IP has to be prepared for each instance, making a total of 3 elastic IPs.
3. Bastion host as a potential alternative would consume extra computing $$$
4. port 22 has to remain open on the internet.

Currently CloudShell does not connect to instances in VPC. System Manager might be a better fit.

instruction to turn off TLS for DICOM traffic

alternative connection option to VPC using VPN

Secret logistics for RDS

Currently Orthweb generates DB secret and stores it to Secret Manager in AWS.

Secret Manager is more expensive than Secure string in System Manager Parameter store

• If continue using Secret Manager, it should be rotated and update to Docker compose
• If secret is intended to be static, use Parameter store instead.

investigate multi-replica configuration for orthanc container

1. set replicase=3 for orthanc containers. [x]
2. rewire port mapping in docker compose (ref). [x]
3. reconfigure envoy proxy configuration to distribute traffic [x]
4. bring envoy proxy version to latest --> outstanding

use SSM endpoint

currently there's no vpc endpoint for ssm

Move Docs to mkdocs

because markdown is getting too long.

configure S3 integration

postgres authentication

currently password is used to authenticate
need to add IAM role authentication on top of it for maximum security

tighten up the resource-based policy

1. S3

• access must come via S3 endpoint (using aws:sourceVpce condition)
• require HTTPS encryption in transit, using aws:SecureTransport
• require server-side encryption, using header
• update routing table if necessary

2. KMS

• create vpc endpoint for KMS
• tighten the key policy to restrict access via endpoint, using aws:sourceVpce

3. Secret manager access

• ensure access via VPC endpoint, using aws:sourceVpce

For those VPC endpoints, no need to use endpoint policy for now.

move private endpoints for s3 and secret manager to private subnet

Multi-az HA using elastic IP

1. introduce an Elastic IP and use its DNS name for HTTPS and DICOM TLS traffic
2. re-configure certificate for elastic IP. Similar to any public IP, an elastic IP also comes with a DNS name ec2-a-b-c-d.compute-1.amazonaws.com
3. introduce a second EC2 instance in the 2nd public subnet. Use public IP of the instances for SSH only.
4. test the process to re-attach elastic IP.
5. update chart.

open issues

1. VPC flow log to s3 bucket -> done
2. s3 access log to s3 bucket -> done
3. database log to cloud watch -> done
4. IMDS v2 support (s3 permission) -> done
   5. semantic version release

use ECS cluster instead of EC2 instance

enable encryption for postgresdb

Revisit DICOM testing with TLS

Consider using dcmtk instead of dcm4che

Error during stack creation

╷
│ Error: Secrets Manager Secret "arn:aws:secretsmanager:us-east-1:434082930953:secret:DatabaseCreds96ea1f2a0c7f35c6-HunT6u" Version "AWSCURRENT" not found
│
│ with data.aws_secretsmanager_secret_version.creds,
│ on secret.tf line 30, in data "aws_secretsmanager_secret_version" "creds":
│ 30: data "aws_secretsmanager_secret_version" "creds" {
│
╵

Terraform error during plan and apply - invalid index for availability_zones.available.names

Hello,

Disclaimer - I'm new to terraform. When I run terraform plan everything looks good except at the very end I see this error below.

Changes to Outputs:

• s3_bucket = (known after apply)
  ╷
  │ Error: Invalid index
  │
  │ on modules/network/main.tf line 39, in resource "aws_subnet" "publicsubnet2":
  │ 39: availability_zone = data.aws_availability_zones.available.names[2]
  │ ├────────────────
  │ │ data.aws_availability_zones.available.names is list of string with 2 elements
  │
  │ The given key does not identify an element in this collection value: the given index is greater than or equal to the length of the collection.
  ╵
  ╷
  │ Error: Invalid index
  │
  │ on modules/network/main.tf line 55, in resource "aws_subnet" "privatesubnet2":
  │ 55: availability_zone = data.aws_availability_zones.available.names[2]
  │ ├────────────────
  │ │ data.aws_availability_zones.available.names is list of string with 2 elements
  │
  │ The given key does not identify an element in this collection value: the given index is greater than or equal to the length of the collection.
  ╵

The instructions didn't mention to do any updates to the data.tf file, but I did try and update that anyway with some values for aws_availability_zones and aws_region, however, when I then tried terraform plan again it complained that data should not be tampered with and is actually supposed to be filled in by the terraform process.

Any idea clue or suggestions regarding this error?

Thank you.

Configure network load balancer

Put EC2 instance in autoscaling group

auto-generate db password

currently password is generated on the client side, and pushed to secrets manager. this is not up to best practices because:

1. the transmission of password over network
2. password is stored in plaintext in terraform state

reference:
https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating_cloudformation.html

modularization with terraform code

Document network route

Document network route, for example:

• access to S3 (PHI) goes through private endpoint
• access to system manager (management traffic) goes through public network

Error downloading zip folder

"When I attempt to download either a ZIP folder ("Download ZIP") or DICOM directory ("Download DICOMDIR"), the download briefly starts but then fails with a Network error. "

Configure second availability zone.

optimize docker compose

• replica
• healthcheck
• network
• resource limit
• ec2 instance size