Please explain requirements for using actions importer in a docker environment secured with Open Policy Agent

[AdrianDsg]

Hi,
When using the actions importer on a shared linux runner (running ubuntu jammy) I faced the following error message.

docker: Error response from daemon: aufhorization denied by plugin opa-docker-authz: request rejected by administrative policy.
See 'docker run --help' .

My knowlege of the Open Policy Agent and the opa-docker-authz docker engine plugin is unfortunately rather limited at this point. I'd be very grateful if you could explain the access control settings required to run the docker image that the actions importer relies on.

Regards,
Adrian

[luke-engle]

Hmm, I don't believe we've tested Actions Importer when using Open Policy Agent. However, based on that error message and the documentation here, it would seem you can't run any docker commands on your system (you could try docker ps to verify that you get the same error message).

In the documentation linked above, the same error message exists toward the end of the 5th step (Test that the policy definition is working). Is it possible for you to modify the policy document to add the allow rule as shown in step 1 of the above documentation?

[Ravio1i]

Hey opa-docker-authz itself is not the problem. Its a common thing in enterprises to use tools like opa to regulate the
usage of docker. The concerning part in actions-importer is that its using "NetworkMode": "Host" (docs). This is basically what opa is blocking.

TL; DR: Running containers in the host network namespace is insecure. Don’t run Docker containers with docker run --net=host . Don’t run Kubernetes Pods with .spec.hostNetwork: true .

• https://stackoverflow.com/questions/35230321/what-are-the-disadvantages-of-a-docker-container-using-the-host-network
• https://medium.com/nttlabs/dont-use-host-network-namespace-f548aeeef575

What is the reason why the docker container for actions-importer requires networkMode=host ?

[AdrianDsg]

I'd be very grateful if someone at GitHub could share some insights on this issue based on the questions of @Ravio1i and myself.
Especially the requirement "NetworkMode": "Host" of the docker image is not yet clear to me.
I understand that the scripts within the docker image are calling the apis of the different parties involved in the migration (e.g. a GitHub Enterprise Server and a Azure DevOps or GitLab Server). Are there any other network operations required?

For the use of the gh-actions-importer with the confidential data of (internal) enterprise customers I'd prefer a clear understanding of all requirements and risks.

[j-dunham]

Hi @AdrianDsg thanks for the question. I have created a internal issue to add a option to not use the host network and hopefully this will address the issues you are having. The main reason we set --network=host is to avoid network issues when the host network is configured differently than Docker's, such as DNS settings.

[gino1312]

Hi, When using the actions importer on a shared linux runner (running ubuntu jammy) I faced the following error message.

docker: Error response from daemon: aufhorization denied by plugin opa-docker-authz: request rejected by administrative policy.
See 'docker run --help' .

My knowlege of the Open Policy Agent and the opa-docker-authz docker engine plugin is unfortunately rather limited at this point. I'd be very grateful if you could explain the access control settings required to run the docker image that the actions importer relies on.

Regards, Adrian

[AdrianDsg]

@j-dunham thanks for your reply and sharing the insights on the networking requirements. To enhance the UX for users of the actions-importer it might be good to add those requirements to the documentation.

When using the actions-importer on a ubuntu image on WSL on a Windows 10 machine I did experience some network issues. However these were related to the authentication with the Azure DevOps Server used to test the migration. I was able to resolve these issues by moving to a machine with a regular ubuntu installation.

Leaving the networking requirements aside are there further requirements required for the docker image? Is there anything related to the storage access?

---

Please consider locking this conversation to contributors (and GitHub Staff) to reduce the noise.

[j-dunham]

Hi @AdrianDsg! We just released version 1.3.3 which adds the CLI flag --no-host-network which will prevent the use of the host network, and use the default bridge network instead. After this version the only known requirement of docker is the ability to create a bind mount in the currently working directory the command is run from. This is so the files generated inside of the docker container can be accessed outside of the container. We also recommend the command not be run in the root directory of the machine running it to avoid possible file permission errors.

To update to the latest version use gh extension upgrade github/gh-actions-importer