HadoopWebApplicationProxy|HadoopWeb应用程序代理服务器

Web Application Proxy

Web Application Proxy 是YARN的一部分。

默认情况下，它将作为资源管理器(RM)的一部分运行，但可以配置为以独立模式运行。
代理的原因是通过YARN减少网络攻击的可能性。

在YARN中，应用程序主(AM)有责任提供一个web UI并将该链接发送到RM。这就引出了一些潜在的问题。
RM作为一个受信任的用户运行，访问该web地址的人将处理它，并将其提供给它们作为受信任的链接，在现实中，AM是作为一个不受信任的用户运行的，它给RM的链接可以指向任何恶意的或其他的东西。
Web应用程序代理通过警告用户不拥有他们正在连接到一个不可信站点的应用程序，从而减轻了这种风险。

此外，代理还试图减少恶意AM对用户的影响。它主要是通过从用户中删除cookie来实现这一点，并使用一个提供用户登录用户名的cookie来替换它们。这是因为大多数基于web的身份验证系统将根据cookie识别用户。通过将这个cookie提供给一个不受信任的应用程序，它打开了开发的潜力。如果正确设计了cookie，它的潜力应该很小，但这只是为了减少潜在的攻击向量。
当前的代理实现并没有阻止AM提供指向恶意外部站点的链接，也不做任何防止恶意javascript代码运行的事情。
实际上，javascript可以用来获取cookie，因此从请求中删除cookie在这个时候是没有什么好处的。

在未来，我们希望解决上面描述的攻击向量，并使附加到AM的web UI更安全。

部署Web Application Proxy

Configuration Property	Description
yarn.web-proxy.address	The address for the web proxy as HOST:PORT, if this is not given then the proxy will run as part of the RM.
yarn.web-proxy.keytab	Keytab for WebAppProxy, if the proxy is not running as part of the RM.
yarn.web-proxy.principal	The kerberos principal for the proxy, if the proxy is not running as part of the RM.

运行 Web Application Proxy
可以使用以下命令启动独立的Web应用程序代理服务器。

$ yarn proxyserver

或者用户可以作为一个守护进程启动独立的Web应用程序代理服务器，使用以下通信。

$ $HADOOP_YARN_HOME/sbin/yarn-daemon.sh start proxyserver

---

官方文档原文

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.