Aws security test staging/live containers

Task 1: Verify that docker remote control of staging and live web site is taking place using client cert authentication

On staging server


user@dev-computer: % ssh -i ~/.ssh/<CustomPrivateKey>.pem -o ProxyCommand="ssh -W %h:%p -i ~/.ssh/<CustomPrivateKey>.pem centos@<bastion_public_ip>" centos@ec2-<docker_public_ip>.<region>.compute.amazonaws.com
[centos@ip-10-99-0-188 ~]$ ls
app_data
[centos@ip-10-99-0-188 ~]$ docker ps
CONTAINER ID   IMAGE                                                                                COMMAND                  CREATED       STATUS       PORTS                                                                                            NAMES
732e957720d3   portainer/portainer-ce:latest                                                        "/portainer -H unix:…"   3 hours ago   Up 3 hours   0.0.0.0:8000->8000/tcp, :::8000->8000/tcp, 9443/tcp, 0.0.0.0:9009->9000/tcp, :::9009->9000/tcp   kencho-gigadb-website_portainer_1
4768f62dcc67   registry.gitlab.com/gigascience/forks/kencho-gigadb-website/production_web:staging   "/docker-entrypoint.…"   3 hours ago   Up 3 hours   0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp                         kencho-gigadb-website_web_1
54ceb5461f1c   registry.gitlab.com/gigascience/forks/kencho-gigadb-website/production_app:staging   "docker-php-entrypoi…"   3 hours ago   Up 3 hours   9000/tcp                                                                                         kencho-gigadb-website_application_1
[centos@ip-10-99-0-188 ~]$

2. On live server

user@dev-computer: % ssh -i ~/.ssh/.pem -o ProxyCommand="ssh -W %h:%p -i ~/.ssh/.pem centos@" centos@ec2-..compute.amazonaws.com [centos@ip-10-99-0-20 ~]$ ls app_data [centos@ip-10-99-0-20 ~]$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES f57a25fdd706 portainer/portainer-ce:latest "/portainer -H unix:…" 3 minutes ago Up 3 minutes 0.0.0.0:8000->8000/tcp, :::8000->8000/tcp, 9443/tcp, 0.0.0.0:9009->9000/tcp, :::9009->9000/tcp kencho-gigadb-website_portainer_1 8b47dcf68a21 registry.gitlab.com/gigascience/forks/kencho-gigadb-website/production_web:live "/docker-entrypoint.…" 5 minutes ago Up 5 minutes 0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp kencho-gigadb-website_web_1 a180228306ad registry.gitlab.com/gigascience/forks/kencho-gigadb-website/production_app:live "docker-php-entrypoi…" 5 minutes ago Up 5 minutes 9000/tcp kencho-gigadb-website_application_1 [centos@ip-10-99-0-20 ~]$


### Task 2: Run ``docker scan`` on the two images (application and web) and create PBI (product backlog item) for future implementation of  recommendations
Since `docker scan` is only available with docker desktop, the other way round is to implement `container_scanning` in gitlab CI/CD pipeline, the official doc could be found at [here](https://docs.gitlab.com/ee/user/application_security/container_scanning/index.html#running-the-standalone-container-scanning-tool). 
However, the multiple images scanning of gitlab container scanning tool is [still under development](https://gitlab.com/groups/gitlab-org/-/epics/3139), it could scan all the images, but if images found to have the  same vulnerability, the pipeline security tab would only show one from either of the images, here is the [deep investigation of this problem](https://gitlab.com/gitlab-org/gitlab/-/issues/6946#note_308554624).
To be short, for example, the following vulnerabilities found in both [registry.gitlab.com/gigascience/forks/kencho-gigadb-website/production_web:live](https://gitlab.com/gigascience/forks/kencho-gigadb-website/-/jobs/1813999598) and [registry.gitlab.com/gigascience/forks/kencho-gigadb-website/production_web:staging](https://gitlab.com/gigascience/forks/kencho-gigadb-website/-/jobs/1813999594):
|   STATUS   |      CVE SEVERITY       | PACKAGE NAME | PACKAGE VERSION |                            CVE DESCRIPTION   |           
| ---------- | ---------- | ---------- | ---------- | ---------- |
| Unapproved | Critical CVE-2021-22945 |     curl     |    7.78.0-r0    | When sending data to an MQTT server, libcurl <= 7.73.0 and 7.78.0 could in some circumstances erroneously keep a pointer to an already freed memory area and both use that again in a subsequent call to send data and also free it *again*.  |
| Unapproved | Critical CVE-2021-22945 |   libcurl    |    7.78.0-r0    | When sending data to an MQTT server, libcurl <= 7.73.0 and 7.78.0 could in some circumstances erroneously keep a pointer to an already freed memory area and both use that again in a subsequent call to send data and also free it *again*. |

But, only `registry.gitlab.com/gigascience/forks/kencho-gigadb-website/production_web:staging`'s vulnerabilities could be found in [security tab](https://gitlab.com/gigascience/forks/kencho-gigadb-website/-/pipelines/415210904/?reportType=CONTAINER_SCANNING). It is because each `container_scanning` section would produce one ``gl-container-scanning-report.json`` report, So when it comes time to merge the two separate reports which both contain same vulnerability,  a race condition occurs, and whichever identifier is encountered first will win, and the subsequent occurrence of the vulnerability will be skipped.

This is the [video walkthrough](https://www.youtube.com/watch?v=iiYrvEPT5Fo) created by gitlab on this reported issue. 

### PBI

### Alternatives
1. https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning.html

### reference
1. https://forum.gitlab.com/t/container-scanning-for-multiple-images/27348
2. https://gitlab.com/gitlab-org/security-products/analyzers/klar/-/blob/efa8e63368df8f2a64c9b395ac913e40ce3f52a2/docs/process-flow.md
3. https://gitlab.com/gitlab-org/gitlab/-/issues/208758

rija / gigadb-website

Aws security test staging/live containers #211

Task 1: Verify that docker remote control of staging and live web site is taking place using client cert authentication