| 13 | | Though the experiment appears to be a cohesive whole, the testbeds that |
| 14 | | loan the resources retain control of those resources. Because testbeds |
| 15 | | retain this control, each testbed may issue credential necessary for |
| 16 | | manipulating the federated resources. For example, a testbed that has |
| 17 | | loaned nodes to an experiment may require the experimenter to present a |
| 18 | | credential issued by that testbed (e.g., an SSH key or SSL certificate) |
| 19 | | to reboot those nodes. The system acquires those credentials on behalf |
| 20 | | of experimenters and distributes them on behalf of testbeds. |
| | 7 | == What machines should run fedd == |
| 22 | | Testbed administrators may use the system to establish regular policies |
| 23 | | between testbeds to share resources across many users of a testbed. |
| 24 | | Similarly, a single user with accounts on multiple testbeds can use the |
| 25 | | same interfaces to coordinate experiments that share his testbed |
| 26 | | resource, assuming sharing those resources does not violate the policy |
| 27 | | of any of the constituent testbeds. |
| | 9 | Depending on what sorts of resources you intend to make available to |
| | 10 | others and what modifications you are willing to make to your testbed, |
| | 11 | you may choose to run fedd in different configurations, with |
| | 12 | functionality partitioned between users and boss. |
| 29 | | = Fedd: The DETER Federation Daemon = |
| | 14 | If you intend to allow fedd to either create projects from whole cloth, |
| | 15 | or to modify the access rights of projects or keys of users, at least |
| | 16 | some of fedd will have to run on boss. You can choose to run a fedd |
| | 17 | install on boss only, or run the main instantiation of fedd on users and |
| | 18 | the project manipulation functionality on boss. This depends on your |
| | 19 | particular comfort level with outside access to boss. Fedd's local |
| | 20 | accesses are all encrypted and controlled via fedids, and potentially by |
| | 21 | SSL as well. |
| 33 | | * Creating and terminating federated experiments |
| 34 | | * Requesting access to remote resources on an experimenter's behalf |
| 35 | | * Granting access to local resources based on the testbed's policy |
| | 26 | Fedd also needs to run a modified ns2 parser to split experiments. |
| | 27 | DETER exports an interface to that parser at |
| | 28 | !https://users.isi.deterlab.net:23235 , and the simplest configuration |
| | 29 | choice is to simply make use of that service. Should you choose to get |
| | 30 | the patches from us and run your own modified ns2 parser, you would |
| | 31 | probably want to run that service on your ops node. |
| 42 | | Creating a federated experiment consists of breaking an annotated |
| 43 | | experiment into sub-experiments, gaining access to testbeds that can |
| 44 | | host those experiments, and coordinating the creation and connection of |
| 45 | | those sub-experiments. Fedd insulates the user from the various |
| 46 | | complexities of creating sub-experiments and dealing with cleanup and |
| 47 | | partial failures. Once an experiment is created, fedd returns |
| 48 | | credentials necessary to administer the experiment. |
| | 35 | The easiest way to get a copy of fedd installed on your machine is to |
| | 36 | download the python distutils tar file and install it. The current |
| | 37 | version is fedd-1.0.tar.gz. |
| 78 | | We adopt public keys as the basis for DFA fedids, but rather than tie |
| 79 | | ourselves to one public key format, we use subject key identifiers as |
| 80 | | derived using method (1) in RFC3280. That is, we use the 160 bit SHA-1 |
| 81 | | hash of the public key. While this allows a slightly higher chance of |
| 82 | | collisions than using the key itself, the advantage of a single |
| 83 | | representation in databases and configuration files outweighs the |
| 84 | | increase in risk for this application. |
| | 66 | * `/usr/local/bin/confirm_sshkey.py` |
| | 67 | * used in certain static project installs, see [FeddConfig configuring] |
| | 68 | * `/usr/local/bin/exp_access_db.py` |
| | 69 | * application to simplify creating experiment creation databases |
| | 70 | * `/usr/local/bin/fedd.py` |
| | 71 | * fedd itself |
| | 72 | * `/usr/local/bin/fedd_client.py` |
| | 73 | * command line tool for accessing fedd services |
| | 74 | * `/usr/local/bin/fedid.py` |
| | 75 | * command line tool for getting fedids from X509 certificates |
| | 76 | * `/usr/local/bin/user_to_project.py` |
| | 77 | * used in dynamic project installs, see [FeddConfig configuring] |
| 88 | | In Emulab, projects are created by users within projects and those |
| 89 | | attributes determine what resources can be accessed. We generalized |
| 90 | | this idea into a testbed, project, user triple that is used for access |
| 91 | | control decisions. A requester identified as ("DETER", "proj1", |
| 92 | | "faber") is a user from the DETER testbed, proj1 project, user faber. |
| 93 | | Testbeds contain projects and users, projects contain users, and users |
| 94 | | do not contain anything. |
| | 81 | == Additional scripts == |
| 105 | | If DETER has fedid:1234 then the name (fedid:1234, "proj1", "faber") |
| 106 | | refers to the DETER user faber in proj1, if and only if the requester |
| 107 | | can prove they are identified by fedid:1234. Note that by making |
| 108 | | decisions on the local names a testbed receiving a request is trusting |
| 109 | | the requesting testbed about the membership of those projects and names |
| 110 | | of users. |
| | 92 | To avoid inadvertently interfering with testbed operation, we suggest |
| | 93 | making modified shadow commands on boss called taddpubkey and |
| | 94 | tgrantnodetype. Note the leading 't' on the shadow commands. You can |
| | 95 | do this by doing the following on boss (where the patch files come from |
| | 96 | wherever you saved them): |
| 112 | | Testbeds make decisions about access based on these three level names. |
| 113 | | For example, any user in the "emulab-ops" project of a trusted testbed may |
| 114 | | be granted access to federated resources. It may also be the case that |
| 115 | | any user from a trusted testbed is granted some access, but that users |
| 116 | | from the emulab-ops project of that testbed are granted access to more |
| 117 | | kinds of resources. |
| | 98 | {{{ |
| | 99 | $ cd /tmp |
| | 100 | $ cp /usr/testbed/sbin/addpubkey . |
| | 101 | $ patch < addpubkey.patch |
| | 102 | $ sudo mv addpubkey /usr/testbed/sbin/taddpubkey |
| | 103 | $ sudo chown root:wheel /usr/testbed/sbin/taddpubkey |
| | 104 | $ sudo chmod 4755 /usr/testbed/sbin/taddpubkey |
| | 105 | }}} |
| 124 | | Once a fedd has decided to grant a researcher access to resources, it |
| 125 | | implements that decision by granting the researcher access to an Emulab |
| 126 | | project with relevant permissions on the local testbed. The terminology |
| 127 | | is somewhat unfortunate in that the fedd is configured to grant access |
| 128 | | based on the global three-level name that includes project and user |
| 129 | | components and implements that decision by granting access to a local |
| 130 | | Emulab project and Emulab user. |
| | 119 | Once the scripts exist, make sure you configure the [allocate] section |
| | 120 | of the configuration file to use them, e.g.: |
| 132 | | The Emulab project to which the fedd grants access may exist and contain |
| 133 | | static users and resource rights, may exist but be dynamically |
| 134 | | configured by fedd with additional resource rights and access keys, or |
| 135 | | may be created completely by fedd. Completely static projects are |
| 136 | | primarily used when a user wants to tie together his or her accounts on |
| 137 | | multiple testbeds that do not bar that behavior, but do not run fedd. |
| | 122 | {{{ |
| | 123 | [allocate] |
| | 124 | addpubkey: /usr/testbed/sbin/taddpubkey |
| | 125 | grantnodetype: /usr/testbed/sbin/tgrantnodetype |
| | 126 | }}} |
| 139 | | Whether to dynamically modify or dynamically create files depends |
| 140 | | significantly on testbed administration policy and how widespread and |
| 141 | | often federation is conducted. In Emulabs projects are intended as |
| 142 | | long-term entities, and creating and destroying them on a per-experiment |
| 143 | | basis may not appeal to some users. However, static projects require |
| 144 | | some administrator investment per-project. |
| | 128 | See the [FeddConfig configuration section] for more detail. |
| 148 | | A federated experiment exports a master testbed's runtime environment |
| 149 | | into the other testbeds. The resulting experiment exports the shared |
| 150 | | file space of the home testbed, though a different filesystem, SMB, is |
| 151 | | used to export it. Emulab events can be sent to nodes throughout the |
| 152 | | federated experiment, though some naming slight-of-hand may be required. |
| 153 | | Users who want to reboot nodes or links in federated testbeds will need |
| 154 | | to access those testbeds directly using the credentials provided by |
| 155 | | fedd. |
| | 132 | If you prefer to live more dangerously, you can download a recent tree |
| | 133 | from the subversion repository on this site and install it. The |
| | 134 | same packages must be installed as for the tar file version. The |
| | 135 | commands to access the subversion repository and install are: |
| 157 | | Currently experiments are described in the same ns2 syntax that DETER |
| 158 | | and Emulab use, except that additional annotations for the testbed on |
| 159 | | which to place each node have been ad dded. (The extension is |
| 160 | | set-node-testbed, and described elsewhere.) The testbed name here is a |
| 161 | | local string meaningful to the experimenter. Each fedd knows some set |
| 162 | | of such strings, and experimenters can also inform fedd of the |
| 163 | | appropriate mapping between local testbed name and fedd address to |
| 164 | | contact. |
| | 137 | {{{ |
| | 138 | $ svn checkout http://fedd.isi.deterlab.net:8088/svn/fedd/trunk some_dir |
| | 139 | $ cd some_dir |
| | 140 | $ make dist |
| | 141 | $ cd dist |
| | 142 | }}} |
| 166 | | An experimenter creates an experiment by presenting it to a fedd that |
| 167 | | knows him or her - usually the fedd on their local testbed - along with |
| 168 | | the master testbed name, local Emulab project to export and local |
| 169 | | mappings. That fedd will map the local user into the global (testbed, |
| 170 | | project, user) namespace and acquire and configure resources to create |
| 171 | | the experiment. A fedd may try different mappings of the experimenter |
| 172 | | into the global namespace in order to acquire all the resources. For |
| 173 | | example a local experimenter may be a member of several local Emulab |
| 174 | | projects that map into different global testbed-scoped projects. |
| | 144 | And from there, install from the tar file in dist, as above. |
| 176 | | Once created the user receives the various keys under which he or she |
| 177 | | can access the sub-experiment services and a local and global name by |
| 178 | | which the experiment can be referenced. (Experiments are identified by |
| 179 | | fedids). The local name is mnemonic and can be used locally to access |
| 180 | | information about the experiment and to terminate it. The experimenter |
| 181 | | can suggest a name when requesting experiment creation. |
| 182 | | |
| 183 | | In order to create a fedid, a key pair is created. The public and |
| 184 | | private keys for the fedid representing the experiment are returned in |
| 185 | | an encrypted channel from fedd to the requesting experimenter. The |
| 186 | | experimenter can use this key pair as a capability to grant access to the |
| 187 | | experiment to other users. |
| 188 | | |
| 189 | | While an experiment exists, experimenters can access the nodes directly |
| 190 | | using the credentials passed back and can acquire information about the |
| 191 | | experiment's topology from fedd. Only the experimenter who created it |
| 192 | | or one given the capability to manipulate it can get this information. |
| 193 | | |
| 194 | | Finally, fedd will terminate an experiment on behalf of the experimenter |
| 195 | | who created it, or one who has been granted control of it. Fedd is |
| 196 | | responsible for deallocating the running experiments and telling the |
| 197 | | testbeds that this experimenter is done with their access. |
| 198 | | |
| 199 | | = Interfaces to fedd = |
| 200 | | |
| 201 | | The fedd interfaces are completely specified in WDSL and SOAP bindings. |
| 202 | | For simplicity and backward compatibility, fedd can export the same |
| 203 | | interfaces over XMLRPC, where the message formats are trivial |
| 204 | | translations. |
| 205 | | |
| 206 | | All fedd accesses are through HTTP over SSL. Fedd can support |
| 207 | | traditional SSL CA chaining for access control, but the intention is to |
| 208 | | use self-signed certificates representing fedids. The fedid semantics |
| 209 | | are always enforced. |
| 210 | | |
| 211 | | There are also several internal interfaces also specified in WSDL/SOAP |
| 212 | | and accessible through XMLRPC used to simplify the distributed |
| 213 | | implementation of fedd. You can read about those in the development |
| 214 | | section. |
