#docker #dockerfile
#docker #dockerfile
Вопрос:
У меня есть служба, которая предоставляет конечную точку, основной целью которой является выполнение пользовательского HTTP-вызова на основе предоставленных данных JSON (URL, порт, тело, заголовки и т.д.). Служба запущена внутри контейнера Docker в облачной среде.
Как мне запретить пользователю совершать циклические вызовы на сам сервер, например. post http://myservice.com/invoke body: {'url': 'localhost:8080/invoke', 'method': 'get'}
и как запретить URL-адреса ‘localhost’, ‘0.0.0.0’ или ‘127.0.0.1’, чтобы сервер не смог найти и вызвать их внутри контейнера и выполнить запросы для незащищенных конечных точек? (например, у моей службы также есть 'stats'
конечная точка, недоступная из общедоступного VPC, но доступная внутри частного VPC, поэтому вызов 'myservice.com/invoke {'url': 'localhost:8080/stats', 'method': 'get'}'
сделает эту конечную точку доступной для пользователя за пределами частного VPC).
Мой простой Dockerfile:
FROM registry.access.redhat.com/ubi8/ubi-minimal
COPY build/my-service-1.0-SNAPSHOT-runner my-service
RUN chmod x my-service
EXPOSE 8080
CMD ["./my-service"]
Спасибо
Комментарии:
1. Я предполагаю, что сервер и клиент находятся на разных компьютерах, поэтому вы не хотите, чтобы пользователь мог отправлять запрос со своего компьютера на localhost на серверном компьютере, верно? Тогда я не понял второй момент, не могли бы вы объяснить немного больше, пожалуйста.
2. обновлено описание проблемы
3. Хорошо, если я правильно понимаю, вы вызываете службу внутри сервера через
http://myservice.com/invoke
конечную точку, и вы хотите иметь возможность вызывать «общедоступные» службы с этой конечной точки, но не «частные». Возможно, вы можете добиться этого с помощью дополнительной службы, которая обрабатывает запросы извне VPC. Для этого может подойти обратный прокси-сервер nginx4. мы ограничили исходящий трафик для ‘myservice’ правилами безопасности облачного провайдера. Единственной оставшейся проблемой являются ‘localhost’ и 127.0.0.1, которые могут быть указаны как ‘url’ в теле запроса. Облачный провайдер не может ограничить этот случай
5. Это имеет смысл, поскольку вы не можете ограничить доступ к своему собственному локальному хосту, это немного странно, в этом смысл использования обратного прокси. Другим решением может быть использование CORS и установка
Access-Control-Allow-Origin
заголовка127.0.0.1
для этих «частных» конечных точек и сохранение доступа изнутри облака, но не извне, поскольку источник запроса будет отличаться отlocalhost
.