Solaris Zones provide a means to create one or more virtual environments on a single operating system instance, shielding applications from details of the underlying hardware. Applications in a zone run in isolation from applications in other zones. They cannot see, monitor or affect processes running in another zone. Zones provide the following features:
_ Security
Network services can be run in a zone, limiting the damage that can be done to the system and other zones in case of a security violation. An intruder that is able to exploit a security hole in an application running in a zone can only do limited damage. The actions possible in a zone are restricted to subset of what is allowed in a normal system. For instance, it is not possible to load custom kernel modules, access kernel memory or create device nodes inside a zone.
_ Isolation
Applications requiring exclusive access to global resources, such as specific usernames or network ports, can run on the same machine using zones. Each zone has its own namespace, completely separate from other zones. Users in a zone are unable to monitor other zones, such as viewing network traffic or the activity of processes.
_ Virtualization
Zones present a virtualized environment to applications, removing the physical details of the hardware from view. This eases redeployment of applications on a different physical machine.
_ Granularity
Since zones are implemented in software, zones are not limited to granularity defined by hardware boundaries. Instead, zones offer sub-CPU granularity. Zones do not require dedicated CPU resources, dedicated I/O devices such as HBAs and NICs, or dedicated physical memory. As a result, even a system with a single processor can be used to host several zones.
_ Transparency
The environment presented to the application in a zone is nearly identical to the standard Solaris OS environment. There are no new, zone-specific APIs or ABIs to which applications must be ported. Some restrictions do exist due to security and isolation requirements. These restrictions mainly affect applications that perform privileged operations or need access to physical devices.
Zones Overview
The global zone encompasses the entire system and is comparable to a normal Solaris OS instance. It has access to the physical hardware and can see and control all processes. The administrator of the global zone can control the system as a whole. The global zone always exists, even when no other zones are configured. Inside the global zone are local zones. These zones are isolated from the physical hardware characteristics of the machine by the virtual platform layer. This layer provides the zones with a virtual network interface, one or more file systems and a virtual console.
Even though the virtual network interfaces may map to the same physical network interface, applications in different zones are prevented from seeing traffic from applications in other zones. Every zone has its own process environment and runs its own set of core Solaris OS services, including inetd(1M), syslogd(1M), rpcbind(1M), and more. Applications running in a zone are unable to see applications running in other zones because of this private process environment. Zones are confined to their own subtree in the file system hierarchy and cannot access file systems of other zones or the global zone. All zones share the same operating system instance and therefore run the same Solaris OS version.
The virtual platform layer is not an emulation layer that translates requests from a zone into some other form or executes them on the zone’s behalf. The role of the virtual platform layer is to instantiate and to connect virtualized resources to a zone. For instance, in the case of a virtual network interface, the virtual platform layer creates a logical interface on top of the physical network interface specified in the zone configuration. The IP address from the zone configuration is configured on the logical interface and it is made available to the zone.
One of the attributes of the logical interface is the zone in which it is configured. The kernel uses this attribute to virtualize the network interface by passing packets to the appropriate zone based on this attribute. A zone only sees packets that are destined for its own logical interfaces. Broadcast or multicast packets are replicated and sent to all zones as appropriate.
Virtualization of file systems in a zone is achieved via a restricted root similar to chroot(2).
A process in a zone is limited to files and file systems that can be accessed from the restricted root. Unlike chroot, a zone is not escapable. The virtual platform layer is responsible for creating the restricted root and mounting the file systems defined in the zone configuration on it.
Process isolation is accomplished by adding a reference to the zone to the process credentials. The kernel has been extended to use the zone ID as a means to restrict visibility of other processes. Only processes with the same zone ID are visible to a process in a zone. This selection is made inside the kernel and not available in utilities such as ps(1) or kill(1), as that would make it possible to subvert the isolation by writing a ps(1) replacement.
As the zone ID is part of the credentials, the user ID namespace is also virtualized in zones. Every zone has its own user ID namespace. As a result, users in different zones with the same uid are in fact distinct users, even though they share the same numerical id. The virtualized user ID namespace also implies that passwords are unique to the zone.
The introduction of Least Privilege in the Solaris OS provides a set of fine-grained privileges to replace the concept of the omnipotent root user. Instead of performing checks against uid 0 to allow privileged operations, the kernel now checks for specific privileges required to perform privileged operations. In the past, it was sufficient to be the superuser to perform mount operations. Now, even the root user must have a specific privilege to perform mount operations. By restricting the privileges of root in the local zone to a set of privileges that are safe in a zone, the root user in a local zone can be given enough power to manage the zone without the ability to affect the system as a whole, such as rebooting the system. Restricting privileges by itself is not sufficient for isolation. Privileges only restrict the operations that can be performed, not the objects on which they are performed. This is accomplished by the isolation that zones provide.
It is therefore possible to delegate local zone administration to users by giving them access to the root account in a local zone. Since a user with uid 0 in one zone is different from a user with uid 0 in another zone, a local zone root user cannot compromise any other zone. However, the global zone root user should still be closely guarded as it has control over the system as a whole, and as such has access to all zones.
Administering Zones
Zone administration tasks can be divided into two parts, global zone administration tasks such as creating a zone, and local zone administration tasks such as performing configuration within a zone. The four primary global zone administration tasks are:
_ Configuration — the global administrator defines the virtual platform properties, such as the required file systems and network interfaces
_ Installation — the global administrator creates the zone on the system by creating and populating the part of the file system hierarchy reserved for the zone
_ Virtual Platform Management — the global administrator uses zone tools to boot, halt or reboot the zone
_ Zone Login — the global administrator can move in and out of the local zone from the global zone to assume the role of the local zone administrator
Zone Configuration
The first step of creating a zone on a system is defining its configuration using the zonecfg(1M) command. The configuration describes resources and properties that are required for the zone to operate:
_ Zone name — A unique name for the zone. This name is only of interest in the global
zone, it is distinct from the nodename of the zone. The name ’global’ and names starting with ’SUNW’ are reserved.
_ Zone path — Every zone has a path to its root relative to the global zone’s root directory. The zone’s root path will be one level deeper; the ’root’ directory under the zone path. To prevent unprivileged users in the global zone from traversing into the file system hierarchy of the zone, the zone path must be owned by root with mode 700. The zone ’root’ directory should be owned by root and have mode 755 like a regular root directory.
_ File systems — a zone may have file systems that should be mounted when the zone is booted
_ Network interfaces — a zone may have one or more virtual network interfaces. The configuration specifies the IP address and the physical interface in the global zone on which it is to be created.
_ Devices — a zone may require devices that need to be configured when the zone is booted. A default set of devices required in every zone is provided and can be imported into the configuration
_ Resource controls — a zone may have resource controls that should be enabled when the zone is booted.
_ Properties — a zone can have properties that control some aspect of the zone, such as the autoboot property. The autoboot property is comparable to the auto-boot? OBP parameter and determines if the zone is to be booted automatically when the global zone is booted.
Installing Zones
The zone configuration process is only concerned with the syntactic correctness of the configuration: it determines if the configuration could be created on some system, not necessarily this particular system. This is verified when the zone is installed on a system using the zoneadm(1M) install command. This command checks to see if all resources, such as the physical network interface specified in the configuration, are available. It then installs the files needed for the zone’s root file system in the correct location under the zone path, and creates the mount points for additional file systems specified in the configuration.
When the installation is complete, the zone is ready to be booted. The root file system of a typical zone requires approximately 100 MB of disk space.
Virtual Platform Management
The virtual platform layer is implemented by the zoneadmd(1M) daemon. When the global administrator boots a zone using the zoneadm boot command, an instance of zoneadmd is created for that zone. The zoneadmd instance for the zone consults the zone configuration and creates a new zone. It then creates the virtual network interfaces, mounts the file systems, and creates the zone virtual console. Finally it starts an instance of init(1M) in the zone to further bringup the zone using SMF.
The global zone administrator can halt the zone using zoneadm halt and reboot the zone using zoneadm reboot. These commands do not perform an orderly shutdown when bringing down the zone. These operations can be considered the equivalent of the setkeyswitch operations on the system controller of larger Sun Fire systems. If an orderly shutdown of the zone is required, an init 0 command should be done from inside the zone to ensure the stop methods of smf(5) services are executed, just like a domain on a Sun Fire server would be shutdown prior to running the setkeyswitch off command.
The svc:/system/zones smf(5) service in the global zone is used for zone startup and shutdown. All zones with the autoboot property set are started automatically when the global zone boots. When the global zone is stopped, the zones service performs an init 0 in each running zone to do an orderly shutdown of services in the zone.
Zone Login
Since zones are implemented in software and require no dedicated hardware, the virtual platform provides a virtual console for each zone. The virtual console can be accessed from the global zone using the zlogin(1M) command with the -C option. The console for a zone cannot be shared by multiple users at the same time. The first user to connect to the console of a zone has exclusive access until disconnecting from the console. Access to the consoles
of other zones is still possible.
When using the zlogin command in interactive, non-console mode an arbitrary number of zlogin sessions to the same zone may be open concurrently. Non-interactive zlogin is also possible, for example to allow the global administrator to perform scripted administration in zones. The use of zlogin requires a specific privilege.
Traditional remote login facilities such as telnet(1), rlogin(1) and ssh(1) can still be used, provided they have not been disabled by the local zone administrator.
Commands
The following commands were added to the Solaris OS for zones:
| Command | Description |
| zonecfg(1M) | Create, update and view zone configuration |
| zoneadm(1M) | Administer zones |
| zlogin(1) | Login to a zone from the global zone |
| zonename(1) | Print the name of the current zone |
| zoneadmd(1M) | Zones administration daemon |
Several existing Solaris OS commands were enhanced to support zones:
| Command | Description |
| prstat(1M) | -Z, -z options added |
| ps(1) | -o zone, -o zoneid options added |
| pgrep(1) | -z option added |
| pkill(1) | -z option added |
| priocntl(1) | -i option added |
| renice(1) | -i option added |
| ipcs(1) | -Z, -z option added |
| ipcrm(1) | -z option added |
| ppriv(1) | -z option added |
| ifconfig(1M) | -Z option added |
| poolbind(1M) | -i option added |
| df(1) | -Z option added |
| coreadm(1M) | %z token added |
Local Zone Administration
Administering the local zone is largely the same as administering a normal Solaris-based system. Some of the administrative facilities are not available in the zone because they do not apply to zones, such as device configuration. After the initial install of the zone by the global administrator, the system is in an unconfigured state. The normal sysid tools are run on the first zone boot to finish zone configuration. The prompts from these tools can be bypassed completely by creating a /etc/sysidcfg configuration file with all required parameters in the zone. Each zone runs its own core Solaris OS services, and therefore has its own name service. Consequently, one zone can use NIS , while another zone can use LDAP, DNS or local files for the name service.
File Systems
A number of file systems are mounted in the zone by the virtual platform layer when the zone is booted. In the default configuration, the following file systems are mounted in a zone:
_ /, the zone root file system is mounted on <zonepath>/root in the global zone
_ /sbin, /usr, /lib and /platform file systems are read-only loopback mounts from the global zone to enable text page sharing to reduce memory requirements. This also reduces the required disk footprint of the zone.
_ /dev for the zone is mounted on <zonepath>/dev in the global zone
_ /proc, /dev/fd, /system/contract, /etc/svc/volatile, /etc/mnttab, /var/run and /tmp
Additional file systems can be mounted in a zone if required, either by adding these file systems to the zone configuration using the zonecfg(1M) command, mounting them from within the zone through the local zone’s /etc/vfstab file, mounting them by hand, or triggered by autofs.
UFS file systems to be mounted in the zone are configured using the zonecfg(1M) command by adding file system resources of type ufs. When the zone is booted, the system automatically mounts these file systems in the zone. This is the recommended and safest way to add UFS file systems to a zone.
Mounting UFS file systems from within the zone requires that the character and block device for the file system be explicitly exported to the zone by the global administrator. The file system can then be created by the local zone administrator. It is important to note that this may expose the system as a whole to the risk of failure as the local administrator has access to the raw device and can possibly induce a panic by corrupting the UFS metadata on the disk. It is, therefore, not recommended to mount file systems in this manner.
Alternatively, the global administrator can create a UFS file system somewhere in the global zone and export this file system as a lofs mount to the zone. This prevents the local administrator from exposing the system to the risk described above.
NFS file systems can be mounted in the local zone, provided that they do not originate from the global zone, since it is not possible for a NFS server to mount its own file systems. See the mount_nfs(1M) manpage for more information. Therefore, zones can be NFS clients of any server except the global zone. Currently zones cannot be NFS servers.
Resource Management
The regular resource management facilities such as resource controls, projects, and more are available inside zones. Because projects are also virtualized inside a zone, each zone has its own project database. This allows a local zone administrator to configure projects and resource controls local to that zone.
Resource Pools
A zone can be bound to a Resource Pool through the pool property of the zone configuration. The zone is bound to the specified pool upon creation of the zone. The pool configuration can only be changed from the global zone. A zone cannot change the pool to which it is bound. Zones cannot span multiple pools, therefore, all processes in a zone run in the same pool. It is however possible to bind multiple zones to the same resource pool.
Extended Accounting
The Extended Accounting framework has been extended for Zones. Each zone has its own extended accounting files for task- and process-based accounting that contain accounting records exclusively for the zone. The extended accounting files in the global zone contain accounting records for the global zone and all local zones. Since the Extended Accounting framework uses a flexible and extensible format, the accounting records are now tagged with the zone name to which they apply. This allows the global zone administrator to extract per zone accounting data from the accounting files in the global zone.
Fair Share Scheduler and Zones
To prevent a local zone from monopolizing the system, the global zone administrator can set zone-wide resource controls. The zone.cpu-shares resource control limits the amount of CPU resources a zone is entitled to in the same way that the Fair Share Scheduler does this for projects. A zone with a higher number of zone.cpu-shares is allowed to use more CPU resources than a zone with a low number of shares. The zone.cpu-shares resource control is configured using the zonecfg(1M) command. Note that this requires the Fair Share Scheduler to be the default scheduler for the system, or that the zones be bound to a pool with a processor set with FSS as the scheduler.
Combined with the regular Fair Share Scheduler inside a zone, this leads to a two-level distribution of CPU resources. First, the zone.cpu-shares configured by the global zone administrator determine the amount of CPU resources to which a zone is entitled. The amount of CPU resources available to the zone is then further distributed across the active projects in the zone according to the project.cpu-shares defined by the local zone administrator.
Resource Controls
All standard resource controls are available inside the local zone and can be used by the local zone administrator to perform resource management in the zone. The global zone administrator can limit the number of lightweight processes (LWPs) created by a zone by setting the zone.max-lwps resource control on a zone.
扫一扫
1271
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
