I have a requirement to create multiple spacewalk 2.2 servers for different networks of the same infrastructure. Each network will have several different kickstart builds... one for VMs one for bare metal... etc

I am looking for advice on how to set up the activation key and origination within each server. The severs will need to be accessed by different groups or people with different functions. For instance a programmer could be allowed to log in and add a local repo or package if needed. Finally, is there any need to use a "universal default" key if I will have multiple kickstart configs?

It would have to be published on a channel before anybody could access it.
I don't really get your question, what about the activation keys is important here? The clients are going to subscribe to a channel on their server and get updates pushed at them down the channel, all you have to do is make sure they have access to the right spacewalk server and you know the proper channel.

I'm wondering since I need to have multiple kickstarts available would it be best to not use the universal default option when creating activation keys for each one.

For now I will need at least two kickstart configs available. One VMware and one bare metal. There will be maybe three groups that need access, engineering, devops and developers. Each group should be able to have access to change the kickstart config if needed - ie, add a custom rpm or tweak a config with a post install script. So I was thinking about creating three organizations so that if something changes and one group needs more or less access we can configure that per organization.

Does that help any? Maybe I really just don't get spacewalk yet and that it the problem

Um... make them their own virtual servers and let them build from a unified base. You let them control the base build and you'll end up with software that only runs in your lab.
Seriously, programmers are like cats...with keyboards.

The programmers don't need to control the base build but they do need to be able to add in the occasional rpm or repo. Most dev groups have a front end team of engineers that manage builds. Let's not assume that this is just for programmers but for application support, devops or any other team that might need to add an rpm.

I don't let them bring a line of code into the environment that hasn't been vetted or developed internally.
The idea you'd let them add external repos you know nothing about?
You'll regret that sooner than you think. You'll end up with crap that only runs on their individual machines, and then they'll hand the problem to you to fix.

Dude.... don't worry about the example I brought before you. This does not have to be a dev adding a program they've written. It could be a junior admin team adding a well known rpm or repo. If you don't know how to do it that's fine but please stop derailing this thread.

I told you in the first post how to do it
I spent the next three telling you it was a bad idea.

Spacewalk isn't how they access external repos, it's your internal repo. If you want to let them access external repos, put them in their Yum-Yum tree, modify the security software, open the firewall port and let them rip it up.

You'll need to have a point before I can stick to it....

Yes I get it's an internal repo. I'm going to close this thread out because this is not going anywhere. Thanks for your concern on the security aspect.