Versions Compared

Key

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

...

  • Configurations include any deployable objects that are used for job execution with Agents, such as workflows, jobs etc.
  • Basically the deployment of jobs that include e.g. calls to OS commands, scripts and binaries, to any Agents should be considered a code injection to a remote machine that requires authentication and authorization.
  • Therefore a configuration is required to be signed by a responsible person:
    • this guarantees that workflows, jobs etc. are authorized for deployment by individuals who are in charge of this task.
    • this guarantees non-reputability repudiability of deployments.
  • JOC Cockpit offers different security levels for deployment tasks.

...

  • To deploy configuration objects includes to transfer e.g. workflows and jobs to a Master in a given environment.
  • This step can be simplified for e.g. development environments when frequent changes occur to configuration objects and deployments are performed with a single mouse click.
  • This step can be more complex if a sharing of responsibilities is included, e.g. to roll-out configuration objects from a development environment to a test or production environment. This situation is called a roll-out and is explained with the subsequent chapter.
  • A secure deployment is adjusted to matches security requirements in a given environment. Therefore the JOC Cockpit can be operated in different Security Levels.
    • Security Levels "low" and "medium" allow simplified deployment and are suitable for environments with modest security requirements.
    • Security Level "high" takes more effort and is targeted towards organisations with more elaborate security requirements.
  • Security Levels are put in place during installation of JOC Cockpit. Each instance of JOC Cockpit can be operated in one of the Security Levels only. There is no fallback from a Security Level "high" to a "medium" or "low" security level. Changing the Security Level requires to reinstall JOC Cockpit.

...

  • Any configuration objects are automatically signed by JOC Cockpit. This tasks task is performed automatically implicitly when deploying objects.
  • This mechanism is easy to use as signing operations are performed implicitly without user interaction.
  • At the same time there is no certainty about who deployed objects as any user who is authorized to deploy objects can use the respective deploy functionality from a single mouse click.

...

  • Configuration objects are signed individually with the private key of the user. This applies within the scope of permissions used in JOC Cockpit to authorize individual accounts for deploying configuration objects.
  • This mechanism is similar to implicit signing except for the fact that the private key stored with the current user's profile is used.
  • Consider that similar to implicit signing all private and public keys of users are stored in a database and therefore are accessible by to a DBA or system administrator.

Security Level High: External Signing

  • Thie The security level requires any configuration objects to be exported and to be signed individually outside of JOC Cockpit.
  • This guarantees that at no point in time JOC Cockpit has any knowledge about the private key used for signing.
  • Security has a price: there is some effort to export a configuration, to sign it and to import the signed configuration.

...

  • A roll-out includes to transfer configuration objects between environments, e.g. from development to test and to production.
  • Steps for a roll-out include
    • that roll-out might include shared responsibilities, e.g being performed by an individual that is different from the person who managed the configuration, e.g.
      • a developer would create workflows and jobs in a development environment and deploy them to Masters and Agents in that environment.
      • an application manager would perform some quality assurance and pick up configurations from a development environment for roll-out to a test environment
      • a release manager would authorize roll-out from a test environment to a production environment.
    • to export a configuration : the affected configuration objects are downloaded to a single archive file (.zip, .tar.gz)
    • to sign the downloaded configuration objects : should the Security Level High be in place including the tasks
      • to transfer the downloaded archive to a secure environment, e.g. a computer that is separated from the network.
      • to extract the archive to disk and to use a program that applies to company standards to sign the files included with the archive. This step includes that the user's private key is used to sign files. As a result for each file extracted from the archive a signature file is created.
      • to add the extracted files and the signature files to an archive file.
    • to transfer the archive with signed files to the target environment. This includes to use any means for file transfer such as copying between servers, use of SCP, SFTP etc.
    • to import the archive with signed files to JOC Cockpit in the target environment.
  • The final step includes to deploy the imported signed configuration objects to the target environment.
    • This task can be performed by the same individual who signed and transferred the archive file or this can require a separate role in JOC Cockpit to be authorized to deploy in the target environment.

...