You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@airflow.apache.org by GitBox <gi...@apache.org> on 2021/07/08 13:15:18 UTC
[GitHub] [airflow] dolevf opened a new pull request #16885: Prevent Redis access directly from host
dolevf opened a new pull request #16885:
URL: https://github.com/apache/airflow/pull/16885
The default `docker-compose.yaml` file exposes Redis to the host by specifying port mapping of `6379:6379`.
Since Redis is unauthenticated by default and runs as root, this poses a risk and will likely be overlooked by users deploying Airflow using docker compose in VPSes or other instances that are publicly facing, even though it's not meant for production use.
I could not find a reason to have Redis be accessible through the host, so I'm proposing to restrict this port from being accessible via the hypervisor.
Redis can be made to write files into the file system using techniques such as [CONFIG SET](https://redis.io/commands/config-set), on a VPS, this will result in a system compromise by a bot within a few hours if not minutes.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] potiuk edited a comment on pull request #16885: Prevent Redis access directly from host
Posted by GitBox <gi...@apache.org>.
potiuk edited a comment on pull request #16885:
URL: https://github.com/apache/airflow/pull/16885#issuecomment-876449588
Should we just remove the mapping altogether? I just tested it and it still works.
The mapping with just the container port still creates a mapping to host (but with ephemeral port number). Removing the mapping makes `redis:6379` only available for the internal docker-compose network, not in the host.
As discussed - it's a development docker-compose, but people might use it as example, so likely it's good to remove it. Unlike webserver/flower (which should be available in the host), I do not imagine that someone might want to have direct access from host to redis (they can still modify the dockerfile if they want) - at least in a normal "user" case.
But for some cases it can be useful. Maybe then we should simply comment out the mapping and add comment specifying why it is commented out and that you might want to uncomment it, if you want to access redis directly ? I think that will be both - development friendly and safe for copy&paste cases.
Also maybe we could - in the same way - create and comment out 5432 port for Postgres container?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] potiuk commented on pull request #16885: Prevent Redis access directly from host
Posted by GitBox <gi...@apache.org>.
potiuk commented on pull request #16885:
URL: https://github.com/apache/airflow/pull/16885#issuecomment-876472602
Ah yeah. Expose is even better.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] potiuk edited a comment on pull request #16885: Prevent Redis access directly from host
Posted by GitBox <gi...@apache.org>.
potiuk edited a comment on pull request #16885:
URL: https://github.com/apache/airflow/pull/16885#issuecomment-876449588
Should we just remove the mapping altogether? I just tested it and it still works.
The mapping with just the container port still creates a mapping to host (but with ephemeral port number). Removing the mapping makes `redis` only available for the internal docker-compose network, not in the host.
As discussed - it's a development docker-compose, but people might use it as example, so likely it's good to remove it. Unlike webserver/flower that it's good to map to host, I do not imagine that someone might want to have direct access from host to redis (they can still modify the dockerfile if they want) - in a normal "user" case.
But for some cases it can be useful. Maybe then we should simply comment out the mapping and (add comment specifying why it is commented out and that you might want to uncomment it, if you want to access redis directly ? I think that will be both - development friendly and safe for copy&paste cases.
Also maybe we could - in the same way - create and comment out 5432 port for Postgres container?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] boring-cyborg[bot] commented on pull request #16885: Prevent Redis access directly from host
Posted by GitBox <gi...@apache.org>.
boring-cyborg[bot] commented on pull request #16885:
URL: https://github.com/apache/airflow/pull/16885#issuecomment-876429920
Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contribution Guide (https://github.com/apache/airflow/blob/main/CONTRIBUTING.rst)
Here are some useful points:
- Pay attention to the quality of your code (flake8, mypy and type annotations). Our [pre-commits]( https://github.com/apache/airflow/blob/main/STATIC_CODE_CHECKS.rst#prerequisites-for-pre-commit-hooks) will help you with that.
- In case of a new feature add useful documentation (in docstrings or in `docs/` directory). Adding a new operator? Check this short [guide](https://github.com/apache/airflow/blob/main/docs/apache-airflow/howto/custom-operator.rst) Consider adding an example DAG that shows how users should use it.
- Consider using [Breeze environment](https://github.com/apache/airflow/blob/main/BREEZE.rst) for testing locally, itโs a heavy docker but it ships with a working Airflow and a lot of integrations.
- Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
- Please follow [ASF Code of Conduct](https://www.apache.org/foundation/policies/conduct) for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
- Be sure to read the [Airflow Coding style]( https://github.com/apache/airflow/blob/main/CONTRIBUTING.rst#coding-style-and-best-practices).
Apache Airflow is a community-driven project and together we are making it better ๐.
In case of doubts contact the developers at:
Mailing List: dev@airflow.apache.org
Slack: https://s.apache.org/airflow-slack
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] potiuk merged pull request #16885: Prevent Redis access directly from host
Posted by GitBox <gi...@apache.org>.
potiuk merged pull request #16885:
URL: https://github.com/apache/airflow/pull/16885
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] potiuk edited a comment on pull request #16885: Prevent Redis access directly from host
Posted by GitBox <gi...@apache.org>.
potiuk edited a comment on pull request #16885:
URL: https://github.com/apache/airflow/pull/16885#issuecomment-876449588
Should we just remove the mapping altogether? I just tested it and it still works.
The mapping with just the container port still creates a mapping to host (but with ephemeral port number). Removing the mapping makes `redis` only available for the internal docker-compose network, not in the host.
As discussed - it's a development docker-compose, but people might use it as example, so likely it's good to remove it. Unlike webserver/flower that it's good to map to host, I do not imagine that someone might want to have direct access from host to redis (they can still modify the dockerfile if they want). Maybe then we should simply comment out the mapping and (add comment specifying why it is commented out and that you might want to uncomment it, if you want to access redis directly ? I think that will be both - development friendly and safe for copy&paste cases.
Also maybe we could - in the same way - create and comment out 5432 port for Postgres container?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] github-actions[bot] commented on pull request #16885: Prevent Redis access directly from host
Posted by GitBox <gi...@apache.org>.
github-actions[bot] commented on pull request #16885:
URL: https://github.com/apache/airflow/pull/16885#issuecomment-876473640
The PR is likely ready to be merged. No tests are needed as no important environment files, nor python files were modified by it. However, committers might decide that full test matrix is needed and add the 'full tests needed' label. Then you should rebase it to the latest main or amend the last commit of the PR, and push it with --force-with-lease.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] boring-cyborg[bot] commented on pull request #16885: Prevent Redis access directly from host
Posted by GitBox <gi...@apache.org>.
boring-cyborg[bot] commented on pull request #16885:
URL: https://github.com/apache/airflow/pull/16885#issuecomment-876473862
Awesome work, congrats on your first merged pull request!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] potiuk edited a comment on pull request #16885: Prevent Redis access directly from host
Posted by GitBox <gi...@apache.org>.
potiuk edited a comment on pull request #16885:
URL: https://github.com/apache/airflow/pull/16885#issuecomment-876449588
Should we just remove the mapping altogether? I just tested it and it still works.
The mapping with just the container port still creates a mapping to host (but with ephemeral port number). Removing the mapping makes `redis:6379` only available for the internal docker-compose network, not in the host.
As discussed - it's a development docker-compose, but people might use it as example, so likely it's good to remove it. Unlike webserver/flower that it's good to map to host, I do not imagine that someone might want to have direct access from host to redis (they can still modify the dockerfile if they want) - in a normal "user" case.
But for some cases it can be useful. Maybe then we should simply comment out the mapping and add comment specifying why it is commented out and that you might want to uncomment it, if you want to access redis directly ? I think that will be both - development friendly and safe for copy&paste cases.
Also maybe we could - in the same way - create and comment out 5432 port for Postgres container?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] dolevf commented on pull request #16885: Prevent Redis access directly from host
Posted by GitBox <gi...@apache.org>.
dolevf commented on pull request #16885:
URL: https://github.com/apache/airflow/pull/16885#issuecomment-876474268
I like the idea of giving people the option for both redis and postgres, maybe instead of inside the docker-compose, it can be referenced in the documentation?
p.s. the restriction requires changing `ports` to `expose, I altered it accordingly.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] potiuk commented on pull request #16885: Prevent Redis access directly from host
Posted by GitBox <gi...@apache.org>.
potiuk commented on pull request #16885:
URL: https://github.com/apache/airflow/pull/16885#issuecomment-876449588
Should we just remove the mapping altogether? I just tested it and it still works.
The mapping with just the container port still creates a mapping to host (but with ephemeral port number). Removing the mapping makes `redis` only available for the internal docker-compose network, not in the host.
As discussed - I think it's a development docker-compose, but people might use it as example, so likely it's good to remove it. Unlike webserver/flower that it's good to map to host, I do not imagine that someone might want to have direct access from host to redis (they can still modify the dockerfile if they want). Maybe then we should simply comment out the mapping and (add comment specifying why it is commented out and that you might want to uncomment it, if you want to access redis directly ? I think that will be both - development friendly and safe for copy&paste cases.
Also maybe we could - in the same way - create and comment out 5432 port for Postgres container?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] dolevf edited a comment on pull request #16885: Prevent Redis access directly from host
Posted by GitBox <gi...@apache.org>.
dolevf edited a comment on pull request #16885:
URL: https://github.com/apache/airflow/pull/16885#issuecomment-876474268
I like the idea of giving people the option for both redis and postgres, maybe instead of inside the docker-compose, it can be referenced in the documentation?
p.s. the restriction requires changing `ports` to `expose`, I altered it accordingly.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] potiuk edited a comment on pull request #16885: Prevent Redis access directly from host
Posted by GitBox <gi...@apache.org>.
potiuk edited a comment on pull request #16885:
URL: https://github.com/apache/airflow/pull/16885#issuecomment-876449588
Should we just remove the mapping altogether? I just tested it and it still works.
The mapping with just the container port still creates a mapping to host (but with ephemeral port number). Removing the mapping makes `redis` only available for the internal docker-compose network, not in the host.
As discussed - it's a development docker-compose, but people might use it as example, so likely it's good to remove it. Unlike webserver/flower that it's good to map to host, I do not imagine that someone might want to have direct access from host to redis (they can still modify the dockerfile if they want) - in a normal "user" case.
But for some cases it can be useful. Maybe then we should simply comment out the mapping and add comment specifying why it is commented out and that you might want to uncomment it, if you want to access redis directly ? I think that will be both - development friendly and safe for copy&paste cases.
Also maybe we could - in the same way - create and comment out 5432 port for Postgres container?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org