CUSTOM Security Policy Maintenance

Document created by rich_patterson Employee on Mar 20, 2015Last modified by Adam Arrowsmith on Feb 20, 2017
Version 4Show Document
  • View in full screen mode

Molecule and Atom Cloud owners have the ability to customize and manage several runtime and security-related policy files that govern forked executions, Atom Workers, and tenant security. This article discusses considerations for managing those files with respect to future AtomSphere platform releases.

 

Important User Guide articles:

 

 

With any given release, in order to support new functionality, security, enhancements, etc, the default or baseline versions of these scripts may change.

 

IMPORTANT: If you have implemented custom versions of these scripts, then it will be your responsibility to review the files for the necessary updates.

 

The following files are examples of which files may have custom versions (the list may not be complete):

  • restart script
  • procrunner policy file
  • procrunner startup script
  • procworker policy file
  • procworker startup script

 

Updates to these scripts will be announced in the Release Notes associated with any given release. The release notes should be reviewed for these updates.

 

After every release, you will notice the atom update, will "touch" the default files, and update their date/time stamp, regardless of whether the content changes. These files are part of our baseline, and get pushed with every release.

 

If you have custom versions of these files specified in your container.properties file, then you should compare your custom versions, with the default versions updated by the release. You should make associated changes as necessary.


For example, in a recent release, in order to support OAuth 2.0, a change was necessary to the procrunner-HIGH.policy file. The corresponding change was necessary to the Account Permissions section:

permission java.io.FilePermission "${com.boomi.container.accountDir}${/}auth${/}-", "read,write,delete";

 

Note:
If your local policies require that these startup scripts be "signed" by your security team, then after each release, because they are updated they will need to be "resigned". If you were to create CUSTOM "copies" of the startup scripts, then you can have these copies signed, and will not have to worry about resigning them after each release (only if they were to require a change as mentioned above).

Attachments

    Outcomes