Page MenuHomePhabricator

Grant cn=nda some sort of read only access to Netbox
Closed, ResolvedPublic


(No clue to tag this, feel free to adjust those if needed)

This is intended to continue discussion from T208267#4712261 and T229710#5900656. Can we grant cn=nda some level of read-only access to Netbox? As a Cloud VPS admin I'd find it useful to be able to see network details of our stack stored there (VLANs, subnets, and the switch port configs related to those on the WMCS infra).

Event Timeline

FWIW, I asked for this when I was not SRE. One complicating factor is that netbox contains serial number of hardware we have and that can be easily abused.

Are hardware serial numbers more abusable / serious than other things we give NDAed people, like logstash, piwik and the other things that come with ?

JMeybohm triaged this task as Medium priority.Mar 7 2022, 9:52 AM

Are hardware serial numbers more abusable / serious than other things we give NDAed people, like logstash, piwik and the other things that come with ?

I don't know. That's not my decision to make TBH. Let me say it another way. Netbox has some "root-level private info" (we do have root-level private info in general, e.g. exim4 logs, that's why they are not being sent to logstash) and that can be disclosed to NDA with a discussion and approval from directors (and possibly security team?). I'm afraid we can't just do it.

ayounsi changed the task status from Open to Stalled.Mar 10 2022, 10:05 AM
ayounsi subscribed.

I suggest we first upgrade Netbox to 3.1 (or most likely 3.2 by the time T296452) that will allow us to clearly see what knobs are available to us for more fine grained access, this will also add more data fields that we might need to hide for NDA.

Once done, we need to list all the fields that could be sensitive even for NDAs (or the other way around).
Then when confident of the solution, loop in managers to approve it.
Finish by (most likely) use:

The scope is different from sharing data publicly as the risk is much lower here, and the data to hide much smaller.
Another idea we had to make data available publicly is to have a public instance, to which is regularly synced redacted dumps of the prod instance. However this is a much heavier process.

ayounsi removed a project: SRE-Access-Requests.

-sre-access-requests for now, to clear the Clinic Duty dashboard.

taavi changed the task status from Stalled to Open.Jun 20 2022, 4:07 PM

Before we talk about technical implementation and putting this on ice. I am wondering..has anyone even had specific concerns or data fields in mind that should be hidden?

Or...asking differently.. how would you actually abuse a Dell server serial?

afaict all you can do with that is lookup what hardware is inside but not the pricing. Procurement tickets were always just private because of the pricing.

This seems like an attempt to introduce 2 levels of NDA, some trust and more trust and a slippery slope.

It started out as a simple request to continue discussion and then somehow turned into "we need to hide fields" and I am wondering what fields are really an issue here and why.

I agree that having more levels of NDA wouldn't be a good path forward. My previous comment was towards auditing if there was anything that shouldn't be accessible by NDA at all.

There are some PII fields that can't be public, for example contact's email and phone number.
There are fields that we initially didn't want to be public to prevent social engineering type of attacks, such as circuit IDs (someone calls their NOC and ask for a change), but some providers expose them publicly and they have been leaked on IRC and tasks.
We might store license keys (T311008), as they're generated based on the device's serial I think they could even be public.
On serials I don't know if someone could for example open bogus support tickets, request spare parts, etc.
Are there anything else?

That said, maybe except the PII mentioned above, I don't think there is anything worth restricting to people under NDA (as read only).

@wiki_willy might know better if it's ok to give NDA people access to Netbox, especially

Before we talk about technical implementation and putting this on ice. I am wondering..has anyone even had specific concerns or data fields in mind that should be hidden?

Or...asking differently.. how would you actually abuse a Dell server serial?

Couple of things:

  • Reporting a device as stolen: . I have no idea what it would mean for us if one of our e.g. servers was reported as stolen, probably nothing good?
  • Finding out hardware configuration, warranty information, date of purchase, etc. Abusers could become creative here and do anything from impersonating us to Dell, to social engineering attacks against us.
  • Dell community forums moderator do point out that it is used to identify as the owner of the system and thus should not be made public:
  • Finally, while we might have an idea what kind of information a service tag currently is tied to, we don't control it and thus can't know/predict what type of information might be tied to it in the future.
  • We don't control it and as such we can't reissue it, revoke it or generally do anything about it being leaked.

Thank you for the examples. That makes sense to me. Especially if Dell advises to keep them secret.

Thanks for checking @ayounsi. My personal opinion on the contacts list is to restrict it if possible. I don't see any issues sharing the generic vendor email addresses and numbers, which is all publicly available anyways, but there are also some individual names of account reps and their contact information listed. If we were to share this (and continue to populate it with future contacts), I think it's appropriate that we check with each individual vendor rep to ensure they're ok with that. And since some reps might be fine with it and others not, it could end up being difficult maintaining the page. I also prefer to block out any specific data center addresses, cage numbers, and rack locations. While I have complete trust in 99% of those with the NDA read-access, I do worry a little about a smaller percentage of potential bad actors down the line. We have experienced threats in the past, so from a security standpoint, the less precise we are with the exact location of our equipment (cage, room, hall, rack, etc), the safer we can keep the hardware and our onsite employees.

With regards to the Dell service tags, there isn't anything too damaging that can be done on the surface - mainly just looking up the internal component information, warranty dates, and support requests. If anything out of the ordinary were to happen, it would likely be flagged to us by our dedicated Dell account team. However to backup Alex's points, I do think a very motivated individual willing to put in the time and effort, could probably figure out how to cause some chaos with our full list of service tags. We also have no guarantee that future server vendors we source would have favorable security measures in place with their particular service tags. So from a security standpoint, I'm thinking that not sharing service tags might be the safer way to go.

@wiki_willy might know better if it's ok to give NDA people access to Netbox, especially

Thank you for your comments everyone! In the interests of not having this stall forever, could we move forward with r/o access to objects that we don't have concerns about?

I played around a bit with the Netbox's demo instance and would maybe propose a list of something like this (obviously without knowing the details on how NB is used around here, so feel free to adjust if I'm missing something):

DCIM > Site, site group, region, locationFor filtering other objects. Note that access to sites seems to display the names of contacts attached to it, but not the actual contact details
DCIM > Rack, rack reservation, rack role
everything(?) under IPAMPreviously public networking information
everything(?) under virtualizationDetails for Ganeti VMs, since concerns about service tags shouldn't apply here

That's missing per-host data, especially the interface details that I'm interested in, but I didn't find a way to grant access to a certain device except a certain field (service tag).

Change 815908 had a related patch set uploaded (by Ayounsi; author: Ayounsi):

[operations/puppet@production] Netbox-next: Allow login from NDA users

Send the above patch to grant access (is_active).

The permissions page though seems to involve quite a lot of manual work see for example:

There is also no mechanism to track new models, on one side it's better to be closed by default, on the other it might make longer term management tedious as well.

This also shows that tracking multiple sets of permissions by groups is not scalable as it. We currently have:

  • wmf (read only, but not on the new models)
  • ops (all access)

Adding NDA seems manageable, more less so.

Setting the same read only rights for WMF and NDA doesn't seem like an option as it might prevent managers from accessing contacts.

Edit: updated as the way it's currently configured in our infra is not how it's now done (eg. on the instance)

I had a quick look at and created a test user there (you can try with user foobar/foobar, the DB is reset every day though)
For contacts it still shows the names on the object pages (circuits, providers), even though it doesn't give access to the contact model (or show more details like phone numbers).

Screenshot from 2022-07-21 11-04-09.png (405×1 px, 53 KB)

So we need to remove access to those as well.

However it's not possible to give access to only some fields of a given object. For example we can't give access to devices and hide the service tag (serial number).
If that's a strict requirement, we need to take a quite different approach (eg. public instance with sanitized data).

Change 815908 merged by Ayounsi:

[operations/puppet@production] Netbox-next: Allow login from NDA users

Change 816118 had a related patch set uploaded (by Ayounsi; author: Ayounsi):

[operations/puppet@production] IDP: allow NDA for netbox and netbox-next

Change 816118 merged by Ayounsi:

[operations/puppet@production] IDP: allow NDA for netbox and netbox-next

After a few back and forth I granted the following permissions to the nda group:

circuits | circuit termination
circuits | circuit type
circuits | provider network
dcim | cable
dcim | cable path
dcim | console port
dcim | console port template
dcim | console server port
dcim | console server port template
dcim | device bay
dcim | device bay template
dcim | device role
dcim | device type
dcim | front port
dcim | front port template
dcim | interface
dcim | interface template
dcim | inventory item
dcim | inventory item role
dcim | inventory item template
dcim | location
dcim | manufacturer
dcim | module
dcim | module bay
dcim | module bay template
dcim | module type
dcim | platform
dcim | power feed
dcim | power outlet
dcim | power outlet template
dcim | power panel
dcim | power port
dcim | power port template
dcim | rack
dcim | rack reservation
dcim | rack role
dcim | rear port
dcim | rear port template
dcim | region
dcim | site group
dcim | virtual chassis
extras | custom field
extras | custom link
ipam | ASN
ipam | FHRP group
ipam | FHRP group assignment
ipam | IP address
ipam | IP range
ipam | RIR
ipam | VLAN
ipam | VLAN group
ipam | VRF
ipam | aggregate
ipam | prefix
ipam | role
ipam | route target
ipam | service
ipam | service template
tenancy | tenant
tenancy | tenant group
virtualization | cluster
virtualization | cluster group
virtualization | cluster type
virtualization | interface
virtualization | virtual machine

Next week or so I'll duplicate it in prod.

After talking to Willy I also granted dcim | device, the reasoning is that it would take considerable efforts to be able to pull something damaging with serial numbers, and we trust NDAs anyway. Devices are also a cornerstone of the DCIM model and it makes Netbox much less useful without it.

Change 817087 had a related patch set uploaded (by Ayounsi; author: Ayounsi):

[operations/puppet@production] Netbox: Allow login from NDA users

Change 817087 merged by Ayounsi:

[operations/puppet@production] Netbox: Allow login from NDA users

@taavi let me know if that works as expected on and feel free to close the task if so.

looks good, thank you!