You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Originally reported by: Jason R. Coombs (Bitbucket: jaraco, GitHub: jaraco)
When one manually destroys a proc in a routed swarm, the routing is unchanged. The load balancer will handle the absence of that proc (assuming there are other procs to handle the load), but if another proc begins to listen on that port, the load balancer will once again route traffic to it. If that proc is from a different app, this can cause unexpected errors or unintended information disclosure (such as when one dispatches my_super_secret_app but traffic intended for everybody_wiki is routed to the sensitive app) or worse.
The first mitigation is to document this behavior here to capture the issue, remind our users that the issue exists, and act accordingly (basically, anytime you manually destroy a proc from a swarm, you should promptly dispatch that swarm).
Originally reported by: Jason R. Coombs (Bitbucket: jaraco, GitHub: jaraco)
When one manually destroys a proc in a routed swarm, the routing is unchanged. The load balancer will handle the absence of that proc (assuming there are other procs to handle the load), but if another proc begins to listen on that port, the load balancer will once again route traffic to it. If that proc is from a different app, this can cause unexpected errors or unintended information disclosure (such as when one dispatches my_super_secret_app but traffic intended for everybody_wiki is routed to the sensitive app) or worse.
The first mitigation is to document this behavior here to capture the issue, remind our users that the issue exists, and act accordingly (basically, anytime you manually destroy a proc from a swarm, you should promptly dispatch that swarm).
The text was updated successfully, but these errors were encountered: