Have you considered Trusted Extensions?  As long as you do not need  
multiple zones of  the same "security context" on the same physical  
server, it might work out for you. (in other words, you cant have two  
"internet" zones on a single host).

This might help you:  

Robert Bailey

On Nov 7, 2008, at 12:13 PM, Tommy McNeely wrote:

> Hello Zones experts,
> We are attempting to create a new data center architecture that favors
> virtualization with zones. Previously, if we wanted to have zones from
> different security contexts (front-end, back-end, internet, etc), they
> had to be in different physical machines (or LDOMS). Now that we have
> the ability (ok, as of s10u4, but we have been busy) to use ipfilter
> between zones on the same host, we believe there may be enough
> separation to have zones in different security contexts on the same
> global-zone.
> I would like to get people's feedback on what they would think of
> creating the ability to have ipfilter rules, that would normally be
> located in ipf.conf in the global zone, inside the zonecfg. When the
> zone is brought "online" it could pipe the rules into "ipf -f -" or
> something. I am thinking the zonecfg seems like a good place to store
> them because when I want to "move" a zone from one machine to another,
> I would prefer the firewall came along with the zone.
> We have discussed using vnic interfaces (crossbow?), but I don't
> believe thats integrated yet? Besides, we don't really trust the
> application administrator (zone administrator) with the firewall, so
> we'd like to keep its configuration in the global zone, which I assume
> would still work even with vnic's.
> QUESTION: If we put the firewall (ipf.conf) inside the zone and use a
> private IP instance, can they can put a "pass out quick on vnic0 keep
> state" and they have the ability to connect to any other zone on the
> same machine? I know that rule in the global zone makes it that way,
> but maybe ip stack instances fix that?
> ~tommy
> _______________________________________________
> zones-discuss mailing list
> zones-discuss@opensolaris.org

zones-discuss mailing list

Reply via email to