cloudlb vs. password_safelist
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	Andrew
	May 16 2023, 4:41 AM

Description

The keystone puppet code sets up the following cidrs:

include ::network::constants
$prod_networks = join($::network::constants::production_networks, ' ')
$labs_networks = join($::network::constants::labs_networks, ' ')
$ldap_rw_host = $ldap_config['rw-server']

Those are later fed to the password_safelist plugin, selectively allowing some password auth to openstack APIs based on which network the request is coming from.

I believe that 172.20.5.0/24 is included as part of 'labs_networks' which means they allow read-only API access but prevent use of the novaadmin user.

Should they be a part of prod_networks instead? Or should we handle them as a special case? As it is, the standard 'novaadmin' user doesn't work for traffic coming through the cloudlbs.

Details

	Subject	Repo	Branch	Lines +/-
	openstack: keystone: be more specific about password ACL	operations/puppet	production	+32 -22
	keystone: service: allow cloud-private supernet	operations/puppet	production	+2 -3

Customize query in gerrit

Related Objects
Search...

Status	Assigned	Task
Resolved	aborrero	T296411 cloud: decide on general idea for having cloud-dedicated hardware provide service in the cloud realm & the internet
Resolved	aborrero	T297596 have cloud hardware servers in the cloud realm using a dedicated LB layer
Resolved	aborrero	T324992 cloudlb: create PoC on codfw
Resolved	aborrero	T332153 cloudlb PoC: prepare backends
Resolved	aborrero	T336723 cloudlb vs. password_safelist

Event Timeline

Andrew created this task.May 16 2023, 4:41 AM

Restricted Application edited projects, added cloud-services-team; removed Patch-For-Review, cloud-services-team (FY2022/2023-Q4). · View Herald TranscriptMay 16 2023, 4:41 AM

Andrew updated the task description. (Show Details)May 16 2023, 4:44 AM

The assumed semantics of the network:constant thingy is challenged here since we're introducing data-center/physical vlan/subnet (traditionally on the prod_network side of it) BUT that is part of the cloud realm (so that makes it more appropriate for the labs_network side).

So I guess we will need to special-case it? Or move it to prod_networks, which may break other stuff elsewhere firewalling-wise.

should the cidr for these hosts get their own network:constants entry? Otherwise I can pass around the list of lb nodes as parameters but I fear we'll wind up doing that a lot.

In T336723#8855269, @Andrew wrote:

should the cidr for these hosts get their own network:constants entry? Otherwise I can pass around the list of lb nodes as parameters but I fear we'll wind up doing that a lot.

Up to you ! It is a bit scary to manipulate the shape of the network::constant structure because really deep/scary inter-dependencies everywhere. Might want to consult with @jbond

In terms of the actual range the allocation for these networks is 172.20.0.0/16.

Probably easier to include that than each individual /24 as we add racks/pops.

Change 920325 had a related patch set uploaded (by Arturo Borrero Gonzalez; author: Arturo Borrero Gonzalez):

[operations/puppet@production] openstack: keystone: be more specific about password ACL

https://gerrit.wikimedia.org/r/920325

gerritbot added a project: Patch-For-Review.May 16 2023, 4:30 PM

Change 920348 had a related patch set uploaded (by Arturo Borrero Gonzalez; author: Arturo Borrero Gonzalez):

[operations/puppet@production] keystone: service: allow cloud-private supernet

https://gerrit.wikimedia.org/r/920348

Change 920348 merged by Andrew Bogott: