[10:35:42] jhathaway: I don't think there is. The short version is that analytics have dedicated vlans on each eqiad row. This policy is applied to traffic going out of those vlans, to prevent data leaking out. [10:40:37] and I think the short and crude version is, the original reasons for having their infrastructure on dedicated vlans, pretty much no longer exist [10:41:07] question_mark: ah? [10:42:19] these days their infrastructure is managed very similarly and well-integrated with the rest of our infrastructure, and I don't see real differences in private data on their infrastructure vs the rest of prod either [10:42:35] this wasn't always the case [10:43:14] that's good to know, thanks! [10:43:36] it would simplifies the infra if we didn't have to make that separation [10:44:07] that's not a decision I'd like to just make like this, so by all means have that discussion with all stakeholers, I'm just indicating that I think the original reasons for it no longer apply ;) [10:44:18] yeah of course :) [10:44:35] I'll open a task to discuss it [10:44:41] great [10:45:36] question_mark: This is interesting. Getting rid of the separate VLAN was discussed as an option on this ticket: https://phabricator.wikimedia.org/T288750 - because we currently have no access to standard LVS services in there. XioNoX: please can you subscribe me to your new ticket? [10:46:14] btullis: will, do, reading your task too [10:46:33] if the decision is to keep separate vlans, we can of course also look at getting standard LVS services setup in those VLANs as well [10:46:43] (which may or may not be significant amount of work) [10:48:04] Great. Thanks. It's not the highest priority, but there are a few places where it would give us better availability. [11:44:34] created https://phabricator.wikimedia.org/T298087 [11:49:13] the more I think about it the more I agree. to leak PII anyone needs to compromise an analytics and an public host [11:49:45] which is the same with the leaking something from a private host [11:51:01] couldn't just use the proxies to send stuff out? [11:52:28] yeah, an APT will just know enough about our infra to use the proxies [11:54:02] APT? [11:55:42] yeah we should not have the proxies open to the world [11:56:19] apt == advanced persistent threat [11:56:48] * volans didn't know it was so dangerous to run apt get :-P [11:57:17] :-) [11:57:38] `sudo apt-get compromize-infrastructure` [11:58:34] dunno if it's fair to mix host FW rules and uid 0 RCE [12:13:29] <_joe_> vgutierrez: I don't think that's what is being done here though, the question is if we need different FW rules for analytics and the rest of production [12:14:22] <_joe_> I think analytics still has data that is unique and interesting in itself, like access logs from the edge [12:15:05] <_joe_> and in general I think most of the rest of production doesn't give you access to the same amount of data/retention [12:22:45] <_joe_> now the next question is: are we ok with host-firewall-level isolation for such data? [12:25:26] _joe_: I think that the vlan firewall rules in question only inhibit traffic /leaving/ the analytics vlan. Host-firewalls are already what is used to restrict traffic inbound to that vlan. [12:25:52] Kerberos is what is used to restrict access to any of the data itself. [12:26:21] <_joe_> btullis: yeah I was referring to egress firewalls [12:29:17] _joe_: OK, understood. [13:26:12] fwiw, that egress rule existed before host level firewalls. It was serving a purpose back then. Not so sure now. [13:26:55] ahem https://phabricator.wikimedia.org/T157806#3075311 [13:26:59] :D [13:27:28] "You do not have permission to view this object." :( [13:27:33] (it was a long time ago I know) [13:30:59] majavah: it is public now, not sure why it was kept with all restrictions, all infos are public :) [13:31:51] it was my first attempt to get rid of the analytics vlan filters :D [13:32:36] but I have to say that with Homer and Capirca handling changes to those filters is really easy (kudos to Riccardo and Arzhel for all that awesome work) [13:33:02] at the time I had to modify routers manually (one at the time) and it was very error prone [17:50:51] jbond, XioNoX: if either of you are still around, my homer apply says mirror1001 is undefined, where do I define it? [17:50:56] ERROR:homer:Device cr2-eqiad.wikimedia.org failed to render the template, skipping. [17:50:59] Traceback (most recent call last): [17:51:01] File "/srv/deployment/homer/venv/lib/python3.7/site-packages/homer/__init__.py", line 287, in _execute [17:51:03] generated_acls = capirca.generate_acls() [17:51:05] File "/srv/deployment/homer/venv/lib/python3.7/site-packages/homer/capirca.py", line 116, in generate_acls [17:51:07] raise HomerError("Capirca error(s)\n" + '\n'.join(failures)) [17:51:09] homer.exceptions.HomerError: Capirca error(s) [17:51:11] Error parsing cr-analytics: [17:51:13] UNDEFINED: mirror1001. [17:51:28] jhathaway: looking [17:51:35] should be pulled from netbox [17:51:53] thanks [17:52:14] jhathaway: for the next time, use a pastebin instead of pasting tons of lines to irc, otherwise the network might dislike you and kick you off [17:52:22] hmm, I wonder why sodium works and not mirror1001 [17:52:34] majavah: sorry will do next time! [17:52:54] maybe some script that needs to be run? [17:53:28] majavah: yep :) [17:53:31] jhathaway: https://netbox.wikimedia.org/extras/scripts/capirca.GetHosts/ [17:54:18] XioNoX: ok, should I press the button? or did you? [17:54:28] jhathaway: go for it [17:54:49] * jhathaway presses button [17:55:47] XioNoX: success, going to try and rerun homer