qa-refapp not inline with RA 2.6

Development
21

It was something else. It was related to:

So I do have a temporary solution, which involves CI doing SSH. It’s not perfect, but it does the trick for now.

I’m really OK with that from the infrastructure perspective, and let me explain a little bit why. It’s always a matter of which perceived risk and benefit.

Several reasons

I made sure of several different things:

  • this machine is completely automated. Recreating it should be reasonably trivial once we have a new machine with the same specs.
  • there’s no important data, no personal data. There’s nothing to be compromised on the machine itself (other than, well, you causing a downtime/outage).
  • if a broken (but not malicious) code gets uploaded, the app is down, which is not a big problem for us.
  • there’s no advantage (network wise) to be inside that machine. One could create another service and open some firewalls, but it’s not like it can be used as a jumpbox.
  • You still need to pass through docker daemon to get to our host machine. That would be a little bit of a somehow sophisticated for us (my mental threat model for openmrs is based on bored 15-old-teenagers and bots scanning the internet).
Things we could improve regardless

That said, the two bits we can improve could be:

  • change our image to run as non-root
  • enable apparmor or something like that in our docker containers

You know what would scare me? If you tell me that an installed module can run arbitrary javascript code on a given browser. If any random person can add code which will execute on my browser, I will make sure to never open my browser there. While that infra server is disposable and has a couple of decent other protections and isolation, my personal computer, my browser has a lot of very important personal info. I have a lot to lose, and I suppose getting someone in our community to click and see a page in our own infra is pretty trivial.

Other thing to keep in mind is that I’d really prefer to reset this server every couple of weeks (to allow new deployments too).

The option is to have a different admin password, and allow this password to be shared with other trusted members (/dev/4 and 5?)

That’s just because I was working on the qa-refapp build and didn’t want to action on this before the result of this discussion :slight_smile:

22

Turns out that that ‘hide details’ feature in discourse pretty much quite literally hide everything collapsed when it sends via email. That’s not very desirable, but well.

If you want to see everything I wrote, please head to talk :slight_smile:

23

So @dkayiwa, do you prefer me to change the module.allow_web_admin=true only or want me to change the admin password as well?

24

Maybe to improve security this server can be reset every week so that whoever is malicious also has to keep uploading the “rogue” module every week to have the desired effect. This way additional security is provided by having the malicious user have to do more work to get adequate results

25

@cintiadr if it does not increase your work by having to deal with its security implications, them am happy with both. Otherwise, i would go with your recommendation. :slight_smile:

26

Side note, do we have a current list of our test servers? I found this document, but it seems out of date:

Take care, Mark

OpenMRS Test environments
27

This should be now done.

I updated modules-refapp to have module_web_admin=true, and also updated the password. I’ve shared with Daniel and others, and we stored in our secret management system as well.

qa-refapp is deployed (and cleaned) of every build of refapp distribution build

modules-refapp is currently scheduled to be redeployed (and cleaned) every Sunday. Feel free to edit. It should be also possible to keep modules installed between deployments. Check https://github.com/openmrs/openmrs-contrib-ansible-docker-compose/ and make the modules folder a volume!

Follow ups on the next servers can be found in OpenMRS Test environments