[ Pobierz całość w formacie PDF ]
.The first component of the principal is called theprimary, or sometimes the user component.The primary component is an arbitrarystring and may be the operating system username of the user or the name of a service.The primary component is followed by an optional section called the instance, whichis used to create principals that are used by users in special roles or to define the hoston which a service runs, for example.An instance, if it exists, is separated from theprimary by a slash and then the content is used to disambiguate multiple principals fora single user or service.The final component of the principal is the realm.The realm issimilar to a domain in DNS in that it logically defines a related group of objects, al-though rather than hostnames as in DNS, the Kerberos realm defines a group of prin-cipals (see Table 6-1).Each realm can have its own settings including the location ofthe KDC on the network and supported encryption algorithms.Large organizationscommonly create distinct realms to delegate administration of a realm to a group withinthe enterprise.Realms, by convention, are written in uppercase characters.Table 6-1.Example Kerberos principalsPrincipal Descriptionesammer@MYREALM.CLOUDERA.COM A standard user principal.User esammer in realm MYR-EALM.CLOUDERA.COM.esammer/admin@MYREALM.CLOUDERA.COM The admin instance of the user esammer in the realm MYR-EALM.CLOUDERA.COM.hdfs/hadoop01.cloudera.com@MYREALM.CLOUDERA.COM The hdfs service on the host hadoop01.cloudera.com in therealm MYREALM.CLOUDERA.COM.At its core, Kerberos provides a central, trusted service called the Key DistributionCenter or KDC.The KDC is made up of two distinct services: the authentication server(AS), which is responsible for authenticating a client and providing a ticket grantingticket (TGT), and the ticket granting service (TGS), which, given a valid TGT, can grant1.IETF RFC 4120 - The Kerberos Network Authentication Service (version 5) - http://tools.ietf.org/html/rfc4120138 | Chapter 6: Identity, Authentication, and Authorization a ticket that authenticates a user when communicating with a Kerberos-enabled (orKerberized) service.The KDC contains a database of principals and their keys, verymuch like /etc/passwd and some KDC implementations (including MIT Kerberos) sup-port storing this data in centralized systems like LDAP.That s a lot of verbiage, but theprocess of authenticating a user is relatively simple.Consider the case where user esammer wants to execute the command hadoop fs -get /user/esammer/data.txt.When operating in secure mode, the HDFS namenode anddatanode will not permit any communication that does not contain a valid Kerberosticket.We also know that at least two (and frequently many more) services must becontacted: one is the namenode to get the file metadata and check permissions, andthe rest are the datanodes to retrieve the blocks of the file.To obtain any tickets fromthe KDC, we first retrieve a TGT from the AS by providing our principal name.TheTGT, which is only valid for an administrator-defined period of time, is encrypted withour password and sent back to the client.The client prompts us for our password andattempts to decrypt the TGT.If it works, we re ready to request a ticket from the TGS,otherwise we ve failed to decrypt the TGT and we re unable to request tickets.It simportant to note that our password has never left the local machine; the system worksbecause the KDC has a copy of the password, which has been shared in advance.Thisis a standard shared secret or symmetric key encryption model.It is still not yet possible to speak to the namenode or datanode; we need to provide avalid ticket for those specific services.Now that we have a valid TGT, we can requestservice specific tickets from the TGS.To do so, using our TGT, we ask the TGS for aticket for a specific service, identified by the service principal (such as the namenodeof the cluster).The TGS, which is part of the KDC, can verify the TGT we provide isvalid because it was encrypted with a special key called the TGT key.If the TGT canbe validated and it hasn t yet expired, the TGS provides us a valid ticket for the service,which is also only valid for a finite amount of time.Within the returned ticket is asession key; a shared secret key that the service to which we speak can confirm withthe KDC.Using this ticket, we can now contact the namenode and request metadatafor /user/esammer/data.txt.The namenode will validate the ticket with the KDC andassuming everything checks out, then performs the operation we originally requested
[ Pobierz całość w formacie PDF ]
