qa-refapp not inline with RA 2.6

@cintiadr, we would like to reset and deploy qa-refapp every green build.

It would be great to be able to reset and deploy modules-refapp on demand only through a CI plan triggered manually in case something breaks.

This is almost done. https://issues.openmrs.org/browse/ITSM-3994

Dockerised qa-refapp: https://qa-refapp.openmrs.org/openmrs/login.htm Dockerised modules-refapp: https://modules-refapp.openmrs.org/openmrs/login.htm Deploy and reset modules-refapp: https://ci.openmrs.org/browse/REFAPP-RM (I will improve the build as well)

The docker-compose files for both are in:

Anything you wanna to change, please just create a PR :slight_smile:

What is missing:

  • deploy qa-refapp on each green build. Give me a day or two to fix it.
  • Update documentation
1 Like

This is awesome @cintiadr :smile: Can we set module.allow_web_admin=true in the runtime properties file for? https://modules-refapp.openmrs.org/openmrs/login.htm

I don’t think we should do this. Letting people upload arbitrary modules is too much of a security risk (because basically they can run arbitrary code on our infrastructure.)

Unless we change things so that people can’t have admin access with a well-known admin password.

Changing module.allow_web_admin=true or the admin password is the same for me. I can even create a couple of other users, and save the database, it shouldn’t be that complicated.

While it is arbitrary code, it’s running inside the JVM and inside docker. While I’m not ignoring that there’s always the possibility of getting out of the container, we are not giving extra permissions to the docker containers we are running.

So, while there’s always risk, it’s not so easy to compromise it compared a ‘regular’ installation outside docker.

In that case, how will developers upload modules to test their compatibility with the reference application?

Turns out I will need to change my webhook scripts in order to allow dockerhub to deploy the same image (openmrs-refapp-distro) to multiple openmrs instances running on the same box.

(For now it’s SSH, and it’s working ~fine, but it’s not the best solution. I will work on that.)

@cintiadr was the SSH line a response to my question of how developers will upload modules to test their compatibility with the reference application? Or were you talking about something else? :slight_smile:

Someone would need to create user accounts for them (via the OpenMRS UI).

Or do you think it’s important that anonymous people be able to upload modules?

I thought we would have the same commonly known account like admin/Admin123 That way, we do not burden ourselves with unnecessarily extra work in addition to blocking someone up to whenever the permission request is granted.

If @cintiadr (representing the infra team) is okay with us allowing module uploads by anonymous people, I’ll go with that.

My own preference is that we do require people to ask us “can I upload a module to the modules-refapp server” and we manually create an account for them the first time. (How often do new people want to do this? There aren’t that many modules out there, or that many module authors.)

Currently, for modules-refapp.openmrs.org, even an admin user account cannot upload modules via the web interface because module.allow_web_admin=false Was this intentional?

It’s intentional that our standard server deployed by the infra team does not allow web management of modules.

I agree with you that for the “module testing server” we need to be more permissive. We just need to decide how permissive.

(I suggest, @dkayiwa, that since you have the most emotional ownership over the modules-refapp server, that you just decide how this should work. You’ve heard what Cintia and I had to say. Now you can make the call.)

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:

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:

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?

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

@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:

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

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