Privileges in Nexus 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, it 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 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 your going to need to make a single group repository per team which 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 like better off using a strategy called "repository partitioning".
Here are some resources that describe this:
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 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:
If you want to learn more about Nexus Repository Manager best practices Sonatype offers a workshop here: