Compose stuff

[nichtsfrei]

To test this you need to first build an local image (to have the fix provided in this pr within the openvas image)

podman build \
  -t registry.community.greenbone.net/community/openvas-scanner:stable \
  -f .docker/prod.Dockerfile .

Adds docker-compose to start openvasd and some test cases.

To start openvasd with http call:

podman-compose -f base.yaml

To start openvasd with https but without mtls:

podman-compose -f base.yaml -f tls.yaml

To start openvasd with mTLS:

podman-compose -f base.yaml -f mtls.yaml

To override the used certificate set the environment variables:

• ${OPENVASD_SERVER_PEM:-./openvasd-server.pem}:/var/lib/openvasd/certs/server.pem:ro
• ${OPENVASD_SERVER_KEY:-./openvasd-server.key}:/var/lib/openvasd/certs/server.key:ro
• ${OPENVASD_CLIENT_KEYS:-./client-certs}:/var/lib/openvasd/certs/clients:ro

If you want to verify your setup you can also deploy the
tests/victim.yaml:

podman-compose -f base.yaml -f mtls.yaml -f tests/victim.yaml

and use the Makefile within tests to create scans:

make create-victim-simple-auth-ssh
make start-victim-simple-auth-ssh
make results-victim-simple-auth-ssh
make status-victim-simple-auth-ssh

The naming scheme of that Makefile is

• create-
• start-
• results-
• stop-
• rm-

and the name of the json within tests/scans without the json suffix.

DEVOPS-1813

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Snapshot Warnings

⚠️: No snapshots were found for the head SHA f03028f.

Ensure that dependencies are being submitted on PR branches and consider enabling retry-on-snapshot-warnings. See the documentation for more information and troubleshooting advice.

Scanned Files

None

[henning]

Trying to test this, after

podman-compose -f base.yaml -f mtls.yaml -f tests/victim.yaml up

it seems like there is a scanner running, but to verify it as the description above says i get:

$ make create-victim-simple-auth-ssh
curl -vk --key ../client-keys/client1.key --cert ../client-certs/client1.pem  -X POST -H "Content-Type: application/json" \
	--data-binary @scans/victim-simple-auth-ssh.json \
	https://localhost:3000/scans | sed 's/"//g' > known-scans/victim-simple-auth-ssh
Note: Unnecessary use of -X or --request, POST is already inferred.
* Host localhost:3000 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying [::1]:3000...
* connect to ::1 port 3000 from ::1 port 53358 failed: Connection refused
*   Trying 127.0.0.1:3000...
* connect to 127.0.0.1 port 3000 from 127.0.0.1 port 47848 failed: Connection refused
* Failed to connect to localhost port 3000 after 0 ms: Couldn't connect to server
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
* Closing connection
curl: (7) Failed to connect to localhost port 3000 after 0 ms: Couldn't connect to server

could be solved by reading the full README from the changed files here, create the certs etc... then it runs.

so besides the above comments this looks good ;)

[henning]

one more thing: while looking into the containers etc in order to try to reproduce the "directories named like the key files that should be there" problem i saw that the victim container still uses an image from your personal account: docker.io/nichtsfrei/victim:latest

[nichtsfrei]

That it is hosted from my account isn't currently considered a problem, as it is only used for testing and is required for running. it is done that way because there is no greenbone equivalent. This was the case also for https://github.com/greenbone/scanner-lab. There is already a ticket to think about a proper solution, currently there is none.