Thomas Sjögren

Hi @xoroz, yeah that makes sense. I'll have a look at it and try to align it with the next CIS release.

I agree it's vague, can you use https://www.ssllabs.com/ssltest/ against your server and see what it recommends?

https://docs.docker.com/compose/completion/ states that `sudo curl -L https://raw.githubusercontent.com/docker/compose/v2.5.0/contrib/completion/bash/docker-compose -o /etc/bash_completion.d/docker-compose` is a valid way to go, but `https://raw.githubusercontent.com/docker/compose/v2.5.0/contrib/completion/bash/docker-compose` is a 404.

https://github.com/docker/docker.github.io/issues/14692

Even if you change /bin/bash to /bin/sh, the script still contains some bashism: ``` console $ sudo dash docker-gc docker-gc: 81: docker-gc: function: not found $ sudo /bin/sh docker-gc docker-gc:...

`date_parse` in the example above can happen if a container is in a running state, and if you convert it to epoch it will be negative. I handled it this...

ansible/ansible-rulebook isn't ansible/ansible and alot of stuff is different and/or not implemented as of now. my suggestion is that you get the environment variables using `os.getenv()` in the event_source instead.

`{{ FALCON_CLIENT_ID }}` would get the environment variable?

thanks @mkanoor for making me aware. one caveat seems to be they have to be quoted and always returned as strings.

Hi @hswong3i, could you please rebase?