Closed Bug 1201985 Opened 9 years ago Closed 9 years ago

Quick ACL check between Marketplace PHX1 host to SCL3 Stage Host

Categories

(Infrastructure & Operations Graveyard :: NetOps: DC ACL Request, task)

Product:
Infrastructure & Operations Graveyard
Component:
NetOps: DC ACL Request
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: jlaz, Assigned: dcurado)

Details

Greetings, 

We moved another set of hosts from bug 1197226 to be racked in SCL3.  Our admin box in PHX1, mktadm1.ops.services.phx1.mozilla.com is unable to reach the current stage host, app1.hsm.stage.addons.scl3.mozilla.com, via SSH.  

We are able to SSH from the addons stage admin host (addonsadm.private.phx1.mozilla.com) in PHX1, but we would like to open ssh + puppet from mktadm1.ops.services.phx1.mozilla.com to the SCL3 HSM stage host (app1.hsm.stage.addons.scl3.mozilla.com).

Thanks!
Or to summarize better:

# allow stage app hsm nodes to prod mkt admin via puppet 

app1.hsm.stage.addons.scl3.mozilla.com
app2.hsm.stage.addons.scl3.mozilla.com

->
mktadm1.ops.services.phx1.mozilla.com 10.32.8.5
mktadm2.ops.services.phx1.mozilla.com 10.32.8.6 tcp/8140 

# allow stage receipt hsm nodes to prod mkt admin via puppet 

receipt1.hsm.stage.addons.scl3.mozilla.com
receipt2.hsm.stage.addons.scl3.mozilla.com

->
mktadm1.ops.services.phx1.mozilla.com 10.32.8.5
mktadm2.ops.services.phx1.mozilla.com 10.32.8.6 tcp/8140 

# allow stage app hsm nodes to prod mkt admin via ssh

app1.hsm.stage.addons.scl3.mozilla.com
app2.hsm.stage.addons.scl3.mozilla.com

->
mktadm1.ops.services.phx1.mozilla.com 10.32.8.5
mktadm2.ops.services.phx1.mozilla.com 10.32.8.6 tcp/22

# allow stage receipt hsm nodes to prod mkt admin via ssh

receipt1.hsm.stage.addons.scl3.mozilla.com
receipt2.hsm.stage.addons.scl3.mozilla.com

->
mktadm1.ops.services.phx1.mozilla.com 10.32.8.5
mktadm2.ops.services.phx1.mozilla.com 10.32.8.6 tcp/22
My apologies, ignore app2.hsm.stage and receipt2.hsm.stage as they do not exist :)
I'll work on this asap.
dealing with a couple of other issues at the moment, but wanted to let you know I did look at this.
Assignee: network-operations → dcurado
Status: NEW → ASSIGNED
bunch of notes...

> # allow stage app hsm nodes to prod mkt admin via puppet
> app1.hsm.stage.addons.scl3.mozilla.com
> ->
> mktadm1.ops.services.phx1.mozilla.com 10.32.8.5
> mktadm2.ops.services.phx1.mozilla.com 10.32.8.6 tcp/8140

The security policy for this is in place, (see below)

> # allow stage receipt hsm nodes to prod mkt admin via puppet
> receipt1.hsm.stage.addons.scl3.mozilla.com
> ->
> mktadm1.ops.services.phx1.mozilla.com 10.32.8.5
> mktadm2.ops.services.phx1.mozilla.com 10.32.8.6 tcp/8140

The security policy for the above has been added.
receipt1.hsm.stage.addons.scl3.mozilla.com has address 10.22.83.128
set security policies from-zone dc to-zone ops policy mktadm--ssh match source-address receipt1.hsm.stage.addons.scl3

> # allow stage app hsm nodes to prod mkt admin via ssh
> app1.hsm.stage.addons.scl3.mozilla.com
> ->
> mktadm1.ops.services.phx1.mozilla.com 10.32.8.5
> mktadm2.ops.services.phx1.mozilla.com 10.32.8.6 tcp/22

The security policy for this is in place, (see below)

> # allow stage receipt hsm nodes to prod mkt admin via ssh
> receipt1.hsm.stage.addons.scl3.mozilla.com
> ->
> mktadm1.ops.services.phx1.mozilla.com 10.32.8.5
> mktadm2.ops.services.phx1.mozilla.com 10.32.8.6 tcp/22

The security policy for the above has been added.

So, some of what you've asked for was already in place.
Here's what the security policy looked like a few minutes ago:
(it's in junos output, but I think you can manage)

Policy: mktadm--ssh, action-type: permit, State: enabled, Index: 316, Scope Policy: 0
  Policy Type: Configured
  Sequence number: 3
  From zone: dc, To zone: ops
  Source addresses:
    receipt1.hsm.stage.addons.scl3: 10.22.83.128/32
    app1.hsm.stage.addons.scl3: 10.22.83.129/32
    receipt2.hsm.svc.scl3: 10.22.16.131/32
    receipt1.hsm.svc.scl3: 10.22.16.130/32
    app2.hsm.svc.scl3: 10.22.16.129/32
    app1.hsm.svc.scl3: 10.22.16.128/32
    peach-gw.peach.metrics.scl3.mozilla.com: 10.22.24.148/32
  Destination addresses:
    mktadm2: 10.32.8.6/32
    mktadm1: 10.32.8.5/32
  Application: junos-ssh
    IP protocol: tcp, ALG: 0, Inactivity timeout: 1800
      Source port range: [0-0]
      Destination port range: [22-22]
  Application: puppet
    IP protocol: tcp, ALG: 0, Inactivity timeout: 1800
      Source port range: [0-0]
      Destination port range: [8140-8140]
  Per policy TCP Options: SYN check: No, SEQ check: No

and now, having added receipt1.hsm.stage.addons.scl3 it looks like this:

Policy: mktadm--ssh, action-type: permit, State: enabled, Index: 316, Scope Policy: 0
  Policy Type: Configured
  Sequence number: 3
  From zone: dc, To zone: ops
  Source addresses:
    receipt1.hsm.stage.addons.scl3: 10.22.83.128/32
    app1.hsm.stage.addons.scl3: 10.22.83.129/32
    receipt2.hsm.svc.scl3: 10.22.16.131/32
    receipt1.hsm.svc.scl3: 10.22.16.130/32
    app2.hsm.svc.scl3: 10.22.16.129/32
    app1.hsm.svc.scl3: 10.22.16.128/32
    peach-gw.peach.metrics.scl3.mozilla.com: 10.22.24.148/32
  Destination addresses:
    mktadm2: 10.32.8.6/32
    mktadm1: 10.32.8.5/32
  Application: junos-ssh
    IP protocol: tcp, ALG: 0, Inactivity timeout: 1800
      Source port range: [0-0]
      Destination port range: [22-22]
  Application: puppet
    IP protocol: tcp, ALG: 0, Inactivity timeout: 1800
      Source port range: [0-0]
      Destination port range: [8140-8140]
  Per policy TCP Options: SYN check: No, SEQ check: No

and hey, notice that the hosts you said no longer exist are still in the policy.
That means, as far as I can tell, that you decomm'd some hosts, but didn't bother to
tell us to remove the firewall configuration for them.
If that's true, um, not so cool.  Let me explain:  if just keep adding and adding and adding
to the firewall configurations, well, their max config size is not infinite.
We're relying on you to not only say, "I need this added" but also to say, 
"I no longer need this."  Thanks.

OK, for the puppet and ssh access that should have been working already, but isn't...
does ping work between those two hosts?

Thanks.
SSH and puppet is confirmed working for the original request.  We're good to go there. 

My apologies for not having mentioned to remove the older entries from the firewall configuration.  I'll be sure to mention or file a separate bug moving forward.  

Much appreciated Dave!
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.