Versions Compared

Old Version 11

changes.mady.by.user Stefan Winter

Saved on

compared with

New Version Current

changes.mady.by.user Marina Adomeit

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

This page and its child pages contains description of individual processes dealing with service operations should be noted as well, such as:

  • Service Order
  • Problem resolution
  • Configuration change
  • System update
  • Backup
  • Disaster recovery

RESPONSIBLE: Information provided here is initially populated by the development team (during the transition phase), and revised based on the need or in a yearly service check by service_name Service Managerperiodically.

Client Root CA Signing Ceremony Playbook

...

  1. S. Winter arrives at GEANT Offices with a Raspberry Pi 3. The Pi has the most recent version of Raspian OS preinstalled, with OpenSSL and the hwrng kernel driver, but no custom software.
  2. The VC begins.
  3. All participants to the ceremony agree on a value "n" for the length of the passphrases. Values smaller than 10 are unacceptable.
  4. S. Winter executes the server CA generation script on the host auth-1.hosted.eduroam.org. This process takes a long time and runs in parallel with the Client Root CA procedures.
  5. The CA generation scripts which are available online at GitHub get downloaded to a USB stick on a computer in GEANT offices.
  6. The Pi gets powered up and connected to a monitor and keyboard available at GEANT offices.
  7. The USB stick gets attached to the Pi, and mounted.
  8. The scripts get copied to local SD card storage.
  9. S. Winter executes the script "CA.bootstrapNewRootCA", answering the interactive questions by the script.
  10. When the script asks for the certificate private key's passphrase, S. Winter makes up a n character password and writes it down on a piece of paper, large enough so that it can be seen when held into the camera of the VC laterin an application on his laptop, for screen sharing.
  11. When the CAs are generated, S. Winter executes the second script, "CA.generateNewIntermediateCA".
  12. When the script asks for the certificate private key's passphrase, S. Winter makes up a different n character password and writes it down on an existing VeraCrypt volume on his laptop.
  13. S. Winter executes the scripts which generate the CRL and OCSP statements, for both the RSA and ECDSA variants.
  14. S. Winter holds up the passphrase to the root CAs into the camera.
  15. M. Milinovic makes a copy of the root CA passphrase and stores it safely for everafter.
  16. S. Winter makes a copy of the root CA passphrase and stores it onto an existing VeraCrypt volume on his own laptop.
  17. S. Winter destroys the piece of paper holding the passphrase. 
  18. S. Winter copies all the public information regarding the CAs onto the USB stick:
    -root CA ECDSA+RSA certificate;
    -intermediate CA ECDSA+RSA certificate;
    -root CA CRL ECDSA+RSA;
    - root CA OCSP statement for the intermediate CA certificates ECDSA+RSA.
  19. S. Winter copies the following SECRET information to the same USB stick:
    -intermediate CA private keykeys, RSA and ECDSA variants.
    -root CA private keys, RSA and ECDSA variants
  20. The USB stick gets unmounted.
  21. The Pi is shut down.
  22. D. Visser extracts the root CA private keys into a word processor document and prints them.
  23. D. Visser  places the Pi and the printouts in its their physical lockup (safe). The access to that safe is managed internally in GEANT according to local procedures.
  24. S. Winter deletes the root CA private keys from the USB stick.
  25. S. Winter copies the remainder of the information on the USB stick to the relevant locations on the VMs.
  26. The group verifies that meanwhile the server CA generation script has finished.
  27. The VC ends.
  28. The ceremony ends.

...

The passphrase to the Root CA private keys is known to the Service Owner (M. Milinovic) and S. Winter (DevOps team). Both of these have no access to the physical storage of the key file.

VM snapshot restore procedure 


1. eduroam-OT sends a request to the GEANT IT Support <support@it.geant.org>, to restore a specific machine, from a given date,

      1-a If the restore is urgent (which IMHO will always be the case), CC qaiser and Allen to the email, and note "URGENT" in subject of the message

      1-b In this message eduroam-OT states if they want that the:

          1-b-1 restored snapshot replace the existing VM, or

          1-b-2 restored snapshot to be separately accessible so that they can manually retrieve the needed information

2. GEANT IT restores the VM as per request, detailed in 1-b.

          2-a The restore time is not guaranteed, as GEANT IT is not 24/7. For urgent ones follow 1-a !!

3. GEANT IT confirms to the eduroam-OT that the restore was complete

4. eduroam-OT confirms that the restore was successful and optionally informs in case of 1-b-2, if the restored VM is no longer needed

5. restore request is closed.