Privileges in Nexus Repository group repositories are transitive, any privilege granted to a group repository is also applied to all of the group's member repositories. This isn't an issue for write privileges, you typically will give write privileges directly on hosted repositories. But it is an issue for read privileges, which means that it is difficult to make a private hosted or proxy repository. If this "private" repository is a member of a group repository that your users have read access to then it isn't private anymore.
And you'll want to be using group repositories for read access, we don't recommend putting multiple repositories in the settings.xml file, maven is a lot less efficient than Nexus Repository at handling multiple repositories. Also, you don't want to be managing repository access by constantly changing settings.xml files, it doesn't scale.
So for controlling read access, you are going to need to make a single group repository per team that has the artifacts they need. So a strategy that can work is to make a group repository that has all of the repositories that are needed across all teams (such as your central proxy) and then make additional group repositories per team that contain the hosted repositories they need access to.
So as a specific example of this strategy:
Team A Group team-a-private Public_Group Maven_Central Cloudera Thirdparty ... Team B Group team-b-private Public_Group Maven_Central Cloudera Thirdparty ....
Note that the Public_Group repository contains everything all teams need.
One thing to be aware of is that repositories are resource intensive, and if you have too many of them performance will suffer. If making group repositories and hosted repositories per team is going to result in a large number of repositories (thousands) then you are better off using a strategy called "repository partitioning".
The trick to making this work for reads is that you'll need to make a repository target privilege that allows access to most artifacts and restricts them to specific ones. If you are at liberty to choose your group ID's now, then one easy way to do this is to put everything that is restricted under a common top-level path. So suppose you choose "/org/someplace/
Then you can make a read privilege based on this regular expression, and grant it to everyone:
This allows access to everything that isn't under "/org/someplace/
After this, you can selectively grant read access to things under that path by making privileges based on regular expressions like this one: