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)

task
Not set
normal

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
Depends on: 913727
i am going to copy :joes from opsec to get official thoughts/approval for this.
Flags: needinfo?(jstevensen)
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)
Flags: needinfo?(mhenry)
Component: Server Operations: Web Operations → WebOps: Other
Product: mozilla.org → Infrastructure & Operations
This isn't a major security concern. This is an acceptable risk.
Flags: needinfo?(mhenry)
: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)
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 ?
Another interpretation : PaaS -> <public_internet_but_not_moz_internal> : tcp/80&443 Yet another interpretation : PaaS -> <opsec_proxies> -> <public_internet> : tcp/80&443
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)
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)
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.
Whiteboard: [change - configuration]
Depends on: 952184
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)
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
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.