Closed
Bug 889509
Opened 12 years ago
Closed 11 years ago
PaaS should have access to public facing Mozilla websites.
Categories
(Infrastructure & Operations Graveyard :: WebOps: Other, task)
Infrastructure & Operations Graveyard
WebOps: Other
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: mythmon, Unassigned)
References
Details
(Whiteboard: [change - configuration])
Currently applications hosted on PaaS cannot communicate with many public Mozilla websites. I assume this is due to the Firewall isolating Stackato from the rest of the Mozilla infrastructure. Sites that are publicly available should be available to PaaS applications.
STR:
From a paas instance's ssh shell:
$ curl -XHEAD http://assets.mozillalabs.com/Brands-Logos/Firefox/logo-wordmark/firefox-aurora_logo-wordmark_RGB-300dpi.jpg
Expected:
A HEAD response is returned.
Actual:
curl: (7) couldn't connect to host
Other sites I tested: mozilla.org, bugzilla.mozilla.org, people.mozilla.com
Comment 1•12 years ago
|
||
i am going to copy :joes from opsec to get official thoughts/approval for this.
Flags: needinfo?(jstevensen)
Comment 2•12 years ago
|
||
I'm not sure what the current state of Stackato security is, so I will hand this over to :tinfoil to answer.
Flags: needinfo?(jstevensen)
Updated•12 years ago
|
Flags: needinfo?(mhenry)
Updated•12 years ago
|
Component: Server Operations: Web Operations → WebOps: Other
Product: mozilla.org → Infrastructure & Operations
Comment 3•12 years ago
|
||
This isn't a major security concern. This is an acceptable risk.
Flags: needinfo?(mhenry)
Comment 4•12 years ago
|
||
:tinfoil, any idea on what the expected solution on this would look like ? In particular, looking for input on how to craft a sane request to NetOps for ACLs.
Flags: needinfo?(mhenry)
Comment 5•12 years ago
|
||
To clarify, this bug requests that the PaaS be allowed to contact 80/tcp and 443/tcp on all "public Mozilla websites", which is actually a much more complex request than it may appear at first glance. Mozilla has publicly-accessible web properties all over the place, including (but not limited to) our own data centres, Amazon, Heroku, and so forth. Furthermore, there are any number of community sites, legacy projects, and so forth, which could be described as public Mozilla websites, but for which we have little to no control (or even visibility).
There is no definitive list of sites, nor IP addresses, nor netblocks - nor could there be, since sites come up and down all the time according to the vagaries of marketing campaigns, technology life-cycles, and community activity.
In other words, we either need to be more precise (but necessarily static and incomplete) :
PaaS -> <our_DC_netblocks> : tcp/80&443
Or cast a much wider net :
PaaS -> * : tcp/80&443
Thoughts ?
Comment 6•12 years ago
|
||
Another interpretation :
PaaS -> <public_internet_but_not_moz_internal> : tcp/80&443
Yet another interpretation :
PaaS -> <opsec_proxies> -> <public_internet> : tcp/80&443
Comment 7•12 years ago
|
||
Opsec doesn't have any proxies. We helped Netops and Infra deploy proxies by ensuring they had a manageable ACL system. (The project started in 2010 with netops and services)
ACL's can be requested through netops:
https://mana.mozilla.org/wiki/display/NOC/ACL+Requests
That being said, the proxies currently already allow full http/https access to all publicly accessible Mozilla websites, so no additional ACL is required unless requesting access to other non-Mozilla websites. If you need to request access, I recommend following the current ACL request process:
https://mana.mozilla.org/wiki/display/NOC/ACL+Requests
I am sorry if my original comment was not clear, I thought the original request was asking for opsec's opinion on if this was an acceptable security risk.
Flags: needinfo?(mhenry)
Comment 8•12 years ago
|
||
The proxy is a potential solution to this problem. It is worth noting that while the major MoCo websites (stuff that is hosted on our DC infra) are accessible via the proxy, anything out in The Cloud (for example) would remain inaccessible.
Mythmon, does this satisfy your request ?
https://mana.mozilla.org/wiki/display/SECURITY/Sitewide+Datacenter+Proxy+FAQ
Flags: needinfo?(mcooper)
Comment 9•12 years ago
|
||
For the record, and for future similar requests, PaaS can have full outbound web access 0.0.0.0:{80,443} through the proxies. However, this particular ACL doesn't exist yet.
Updated•12 years ago
|
Whiteboard: [change - configuration]
Reporter | ||
Comment 11•12 years ago
|
||
Using a proxy would work for my applications. I did a quick test on one of the Stackato applications I use, and it seems to work. It would be great if this http_proxy setting could be pre-set on Stackato instances, instead of users having to know to set up a proxy.
Test:
corsica.paas.allizom.org:~$ echo $HTTP_PROXY
corsica.paas.allizom.org:~$ echo $http_proxy
corsica.paas.allizom.org:~$ wget -XHEAD --server-response -q people.mozilla.org
corsica.paas.allizom.org:~$ # No output: no connection was made.^C
corsica.paas.allizom.org:~$ export http_proxy="http://proxy.dmz.phx1.mozilla.com:3128/"
corsica.paas.allizom.org:~$ wget -XHEAD --server-response -q people.mozilla.org
HTTP/1.0 200 OK
Date: Mon, 20 Jan 2014 18:50:49 GMT
Server: Apache
X-Backend-Server: people1.dmz.scl3.mozilla.com
Last-Modified: Tue, 15 May 2012 22:34:13 GMT
ETag: "c7"
Accept-Ranges: bytes
Content-Length: 199
Content-Type: text/html; charset=UTF-8
X-Cache: MISS from proxy4.dmz.phx1.mozilla.com
X-Cache-Lookup: MISS from proxy4.dmz.phx1.mozilla.com:3128
Via: 1.0 proxy4.dmz.phx1.mozilla.com (squid/3.1.10)
Connection: keep-alive
Flags: needinfo?(mcooper)
Comment 12•11 years ago
|
||
we've decided that use of the http_proxy in stackato should be optional and not applied to all lxc containers by default. part of this decision is that activestate doesn't support lxc container customization and if we do make changes to the default container, this will break in the next version of stackato (3.2) we're planning to deploy since they've moved to docker.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
Updated•6 years ago
|
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•