hadoop-yarn-project/hadoop-yarn/hadoop-yarn-site/src/site/apt/WebApplicationProxy.apt.vm

~~ Licensed under the Apache License, Version 2.0 (the "License");
~~ you may not use this file except in compliance with the License.
~~ You may obtain a copy of the License at
~~
~~   http://www.apache.org/licenses/LICENSE-2.0
~~
~~ Unless required by applicable law or agreed to in writing, software
~~ distributed under the License is distributed on an "AS IS" BASIS,
~~ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
~~ See the License for the specific language governing permissions and
~~ limitations under the License. See accompanying LICENSE file.

  ---
  YARN
  ---
  ---
  ${maven.build.timestamp}

Web Application Proxy

  The Web Application Proxy is part of YARN.  By default it will run as part of
  the Resource Manager(RM), but can be configured to run in stand alone mode.
  The reason for the proxy is to reduce the possibility of web based attacks
  through YARN.

  In YARN the Application Master(AM) has the responsibility to provide a web UI
  and to send that link to the RM.  This opens up a number of potential
  issues.  The RM runs as a trusted user, and people visiting that web
  address will treat it, and links it provides to them as trusted, when in
  reality the AM is running as a non-trusted user, and the links it gives to
  the RM could point to anything malicious or otherwise.  The Web Application
  Proxy mitigates this risk by warning users that do not own the given
  application that they are connecting to an untrusted site.

  In addition to this the proxy also tries to reduce the impact that a malicious
  AM could have on a user.  It primarily does this by stripping out cookies from
  the user, and replacing them with a single cookie providing the user name of
  the logged in user.  This is because most web based authentication systems will
  identify a user based off of a cookie.  By providing this cookie to an
  untrusted application it opens up the potential for an exploit.  If the cookie
  is designed properly that potential should be fairly minimal, but this is just
  to reduce that potential attack vector.  The current proxy implementation does
  nothing to prevent the AM from providing links to malicious external sites,
  nor does it do anything to prevent malicious javascript code from running as
  well.  In fact javascript can be used to get the cookies, so stripping the
  cookies from the request has minimal benefit at this time.

  In the future we hope to address the attack vectors described above and make
  attaching to an AM's web UI safer.