(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).
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | ayounsi | T302870 Grant cn=nda some sort of read only access to Netbox | |||
| Resolved | ayounsi | T296452 Upgrade Netbox to 3.2 | |||
| Stalled | None | T234997 Make Netbox Active/Active | |||
| Resolved | ayounsi | T311385 Netbox and Redis | |||
| Stalled | None | T330084 gdnsd failures when converting services from active/passive to active/active |
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 https://wikitech.wikimedia.org/wiki/SRE/LDAP/Groups#NDA_group ?
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.
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: https://netbox.readthedocs.io/en/stable/administration/permissions/
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.
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 https://netbox.wikimedia.org/tenancy/contacts/
Couple of things:
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 https://netbox.wikimedia.org/tenancy/contacts/
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):
| right | notes |
| DCIM > Site, site group, region, location | For 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 IPAM | Previously public networking information |
| everything(?) under virtualization | Details 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: https://demo.netbox.dev/admin/users/objectpermission/
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:
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 demo.netbox.dev instance)
I had a quick look at demo.netbox.dev 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).
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 netbox.wikimedia.org and feel free to close the task if so.