-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add no-sandbox
arg to browser enabled Docker image
#3340
Conversation
In order to allow chrome to execute in the browser enabled image, either SYS_ADMIN Docker capability or no-sandbox browser argument had to be set. This commit sets the 'no-sandbox' option in the Dockerfile definition itself so this action is no longer necessary to run the Docker container. This is arguably also the better option, as we are running the chrome browser inside a container, versus using the Docker capability.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this! Makes things simpler for users. LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice 👍 Documentation updates await 😅 I can help.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not familiar with this arg, but the change looks good 👍
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## master #3340 +/- ##
=======================================
Coverage 73.17% 73.17%
=======================================
Files 258 258
Lines 19887 19886 -1
=======================================
Hits 14552 14552
+ Misses 4414 4413 -1
Partials 921 921
Flags with carried forward coverage won't be shown. Click here to find out more.
☔ View full report in Codecov by Sentry. |
It seems to be not really safe and we should research for alternatives. https://www.google.com/googlebooks/chrome/med_26.html We should open a dedicated issue for researching alternatives. Here is an example: https://github.com/Zenika/alpine-chrome#-the-best-with-seccomp I'm fine with it if we make it temporary, we document it and we are clear on the risks. |
We are aware of this, but considering that in our case the browser runs in a container, the But I agree, if we stick to the |
What?
Sets the
no-sandbox
chrome argument by default through theK6_BROWSER_ARGS
ENV variable in the Dockerfile definition for the browser enabled docker image.Why?
In order to allow chrome to execute in the browser enabled image, either
SYS_ADMIN
Docker capability orno-sandbox
browser argument had to be set. This sets theno-sandbox
option in the Dockerfile definition itself so this action is no longer necessary to run the Docker container. This is arguably also the better option, as we are running the chrome browser inside a container, versus using the Docker capability.Checklist
make ci-like-lint
) and all checks pass.make tests
) and all tests pass.