Grid Security Infrastructure GSI

1
Grid Security Infrastructure (GSI)
2
Overview of GSI

• GSI Key Concepts
• http//www-unix.globus.org/toolkit/docs/3.2/gsi/k
  ey/index.html
• Based on public key cryptography
• Motivated by
• Need for secure, authenticated communication in
  the Grid
• Need to support security across organizations,
  but without central management
• Need to support single sign-on, including
  delegation of credentials for computations that
  involve multiple resources and/or sites

3
Basics

• Public-key cryptography
• Two keys, private and public, one to encrypt, one
  to decrypt
• Digital signature
• A hash of the message, encrypted with my private
  key
• Certificate
• My public key, digitally signed by the
  Certificate Authority
• IF you trust the CA, AND believe that you have
  the public key of the CA, THEN you can believe
  that the public key in the message is mine

4
Basics

• Mutual authentication
• If two parties have certificates, and both
  parties trust the CA that signed the others
  certificate, then the two parties can prove to
  each other that they are who they say they are
• Confidential communication
• Encrypted communication is NOT the default in
  GSI. However, the public keys can be used to
  exchange a shared secret key for encrypted
  messages if desired

5
Grid security technologies

• Security for Grid Services, Welch et. all,
  http//www.globus.org/security/GSI3/GT3-Security-H
  PDC.pdf
• Security is NOT based on interorganizational
  trust relationships
• It is based on the use of a virtual organization
  (VO) as a bridge among entities in a particular
  community or function

6
Grid security requirements

• Must support scalable, dynamic, distributed VOs
• Key attributes of VOs is that
• Participants and resources are governed by
  classical organizations of which they are members
• Some VOs are long-lived, other short lived, so
  the overhead of security must be small

7
Grid security requirements

• VO access must be established and coordinated
• Between the local user and the organization
• Between the VO and the user
• Can NOT assume trust relationships between the
  classical organization and the VO or its external
  members

8
Acquiring certificates

• http//www.globus.org/gt2.4/admin/guide-verify.htm
  lcert
• All users and services need to have a certificate
  issued from a trusted certificate authority (CA).
  
• It is highly recommended that the builders of
  production grids either establish their own
  trusted CA or use an established commercial CA.
• The SimpleCA package can be used to run your own
  CA.

9
Acquiring user and host certificates

• To request a user certificate, simply run
  "grid-cert-request on a system that has GT3
  installed.
• grid-cert-request will ask for a password to
  protect your key, and give you a set of
  instructions for how to mail your request to the
  CA.

10
grid-cert-request

• When you run the grid-cert-request command, it
  will generate three files.
• usercert_request.pem the request that you need
  to send to the CA
• userkey.pem contains the private key
• usercert.pem, which will be a 0 byte file. This
  is not your certificate! It is merely a
  placeholder that helps to remind you where to put
  your certificate when the CA responds to your
  request.

11
User and host certificates

• First double-check the subject.
• Send the request to your Certificate Authority
  via email.
• When you retrieve your certificate, save it to
  /.globus/usercert.pem.
• Do not lose this file, and do not forget your
  password.
• A similar process is followed for a host
  certificate

12
Securing private keys

• Core GSI does not store private keys in an
  encrypted format
• It relies on the protection mechanism of the
  local file system to store private keys

13
Delegation and single sign-on

• If a Grid computation requires that several Grid
  resources be used (each requiring mutual
  authentication), or if there is a need to have
  agents (local or remote) requesting services on
  behalf of a user, the need to re-enter the user's
  passphrase can be avoided by creating a proxy.

14
Proxy certificate

• A proxy consists of
• A new certificate (with a new public key in it)
  and a new private key.
• The new certificate contains the owner's
  identity, modified slightly to indicate that it
  is a proxy.
• The new certificate is signed by the owner,
  rather than a CA.
• The certificate also includes a time notation
  after which the proxy should no longer be
  accepted by others.

15
Use of proxy certificate
16
Use of proxy certificate

• The proxy's private key must be kept secure, but
  not for very long
• Usually the proxy's private key is kept in a
  local storage system without being encrypted
• File permissions prevent anyone else from looking
  at them easily.
• Once a proxy is created and stored, the user can
  use the proxy certificate and private key for
  mutual authentication without entering a
  password.

17
Proxy certificate chain of trust

• The remote party receives the proxy's certificate
  (signed by the owner), and also the owner's
  certificate.
• During mutual authentication, the owner's public
  key (obtained from the certificate) is used to
  validate the signature on the proxy certificate.
• The CA's public key is then used to validate the
  signature on the owner's certificate.
• This establishes a chain of trust from the CA to
  the proxy through the owner.

18
Creating a proxy certificate

• To create a proxy with the default expiration (12
  hours), run the grid-proxy-init program.  For
  example
• grid-proxy-init
• The subject of a proxy certificate is the same as
  the subject of the certificate that signed it,
  with /CNproxy added to the name. 
• A host gatekeeper will accept job requests
  submitted by the user, as well as any proxies he
  has created. 

19
GSI system configuration

• GSI Directories
• Trusted CA directory contains the CA
  certificates and associated files trusted by the
  globus installation
• Grid Security directory contains symbolic links
  to the certificate request configuration files

20
GSI client-side authorization

• A client has every right to be picky about what
  services it accesses, but it is not common
• None No authorization will be performed
• Self the will authorize an invocation if the
  service's identity is the same as the client
  (based on X.509 subject in the certificate or
  proxy).
• Host the client will authorize an invocation if
  the host returns an identity containing the
  hostname

21
GSI server side authorization

• None no authorization is needed to use this
  service
• Self client will be allowed to use a grid
  service if the client's identity is the same as
  the service's identity
• Gridmap a list of 'authorized users' akin to an
  ACL (Access Control List).

22
grid-mapfile

• GT3 Grid Security Infrastructure Overview, Gawor,
  et al. http//www-unix.globus.org/security/gt3-sec
  urity-overview.doc
• A file containing entries mapping X.509
  certificate subjects to local user names.
• This file can also serve as an access control
  list for GSI enabled services
• Is typically found in
• /etc/grid-security/grid-mapfile.

23
GT3 job invocation
24
GT3 job invocation

• The user generates a job instantiation request
  with a description of the job to be started.
• The user then signs this request with their GSI
  proxy credentials
• User sends the signed request to the Master
  Managed Job Factory Service (MMJFS) on the
  resource.
• The MMJFS runs in a non-privileged account.
• MMJFS verifies the signature on the request and
  establishes the identity of the user who sent it.
  
• It then determines the local account in which the
  job should be run.
• Currently this is done by using the grid-mapfile
  and user's grid identity.

25
GT3 job invocation

• Assuming the user does not already have a Local
  Managed Job Factory Service (LMJFS) running in
  their account, the MMJFS invokes the setuid
  starter process to start one.
• The setuid starter is a small setuid program
  running with root privileges that has the sole
  function of starting LMJFS in user's account.
• Once the LMJFS starts up, it uses the Grid
  Resource Identity Mapper (GRIM) to acquire a set
  of credentials.
• GRIM is a setuid program that accesses the local
  host credentials and from them generates a proxy
  for the LMJFS.
• This proxy credential has embedded in it the
  user's Grid identity, local account name and
  local policy about the user.
• The latter policy is obtained from the Grid map
  file entries that apply to that local account.

26
GT3 job invocation

• The MMJFS forwards the original user-signed job
  instantiation request from the user to the LMJFS.
  
• The LMJFS verifies the signature on the request
  to make sure it has not been tampered with and to
  make sure it was created by a user that is
  authorized to run in the local user account.
• The LMJFS instantiates a Managed Job Service
  (MJS), presents it with the users request, and
  returns a reference to the MJS to the user.
• The user connects to the MJS.
• The user and MJS perform mutual authentication
• The MJS authorizes the user as a valid user to
  access the local account it is running in.
• The user authorizes the MJS as having a
  credential issued from a appropriate host
  credential and containing a Grid identity
  matching it's own, thus verifying the MJS it is
  talking to is running not only on the right host,
  but in an appropriate account.
• The user would then delegate GSI credentials to
  the MJS for the job to use and start the job
  running.

27
Community Authorization Service (CAS)

• A Community Authorization Service for Group
  Collaboration, Pearlman, et. al,
  http//www.globus.org/research/papers/CAS_2002_Rev
  ised.pdf
• CAS allows resource providers to specify
  course-grained access control policies in terms
  of communities as a whole
• Fine-grained access control policy management is
  delegated to the community itself
• Resource providers are spared day-to-day policy
  administration tasks (e.g. adding and deleting
  users, modifying user privileges).

28
CAS server

• A CAS server is initiated for a community
• A community representative acquires a GSI
  credential to represent that community as a
  whole, and then runs a CAS server using that
  community identity.

29
CAS server

• Resource providers grant privileges to the
  community.
• Each resource provider verifies that the holder
  of the community credential represents that
  community and that the community's policies are
  compatible with the resource provider's own
  policies.
• Once a trust relationship has been established,
  the resource provider then grants rights to the
  community identity, using normal local mechanisms
  (e.g. gridmap files and disk quotas, filesystem
  permissions, etc.)

30
CAS server

• Community representatives use the CAS to manage
  the community's trust relationships
• For example, to enroll users and resource
  providers into the community according to the
  community's standards) and grant fine-grained
  access control to resources.
• The CAS server is also used to manage its own
  access control policies
• Gor example, community members who have the
  appropriate privileges may authorize additional
  community members to manage groups, grant
  permissions on some or all of the community's
  resources, etc.

31
CAS server

• When a user wants to access resources served by
  the CAS, that user makes a request to the CAS
  server.
• If the CAS server's database indicates that the
  user has the appropriate privileges, the CAS
  issues the user a GSI restricted proxy credential
  with an embedded policy giving the user the right
  to perform the requested actions.

32
CAS server

• The user then uses the credentials from the CAS
  to connect to the resource with any normal Globus
  tool (e.g. GridFTP).
• The resource then applies its local policy to
  determine the amount of access granted to the
  community, and further restricts that access
  based on the policy in the CAS credentials
• This serves to limit the user's privileges to the
  intersection of those granted by the CAS to the
  user and those granted by the resource provider
  to the community.

33
References cited

• GSI Key concepts
• http//www-unix.globus.org/toolkit/docs/3.2/gsi/k
  ey/index.html
• Security for Grid Services, Welch et. all,
  http//www.globus.org/security/GSI3/GT3-Security-H
  PDC.pdf
• http//www.globus.org/gt2.4/admin/guide-verify.htm
  lcert
• GT3 Grid Security Infrastructure Overview, Gawor,
  et al. http//www-unix.globus.org/security/gt3-sec
  urity-overview.doc
• A Community Authorization Service for Group
  Collaboration, Pearlman, et. al,
  http//www.globus.org/research/papers/CAS_2002_Rev
  ised.pdf