SugarCloud Policy Guide
This guide provides information about the various policies and practices employed by SugarCRM's SaaS cloud service.
Integrating with SugarCloud
SugarCRM is actively moving toward a middleware integration policy. The recommended and safest mechanism for integrating with Sugar is through the use of our REST APIs. The current integration method using module-loadable packages is problematic for a number of reasons. Module-loadable packages are not being deprecated at present, however, we are working toward a model where they can be removed in the future. Module-loadable packages can call private, internal application APIs that are not guaranteed to behave the same between releases. This deep-linking model causes issues for both SugarCRM and the independent software vendor because there is no well-defined, testable surface area that can be tested between releases to ensure compatibility for integrations.
We recognize that not all of the hooks are present today to accomplish everything using middleware. Please help us to ensure that we are providing the necessary hooks by raising bugs and enhancement requests where appropriate. We believe that most customizations can be achieved through a combination of robust APIs and web-hook-based callbacks.
Third-party modules installed in a hosted environment decrease overall security, as running untrusted code will always increase the surface area for attack. At present, we support dynamically loadable modules in our cloud environment provided they are compatible with the Package Scanner. Disabling the Package Scanner in a SugarCloud instance is strictly forbidden and constitutes a violation of the Sugar Master Subscription Agreement.
It is expected that all customized files in a cloud instance are installed via Module Loader. The Sugar Support team will not execute requests to copy individual files into a cloud instance.
The Package Scanner provides a mechanism to blacklist certain function and method calls which cause performance problems or could potentially be used to bypass security mechanisms in the hosted environment. If you wish to deploy your customization to a cloud instance, it is imperative that you test loading it with Package Scanner enabled and work around any issues raised. You can enable Package Scanner in your local development environment by setting the following in the
$sugar_config['moduleInstaller']['packageScan'] = true;
For details on the Package Scanner and a listing of blacklisted functions, please visit the Developer Guide specific to your version.
You should note that Sugar's cloud service does not allow the overwriting of Sugar core files with customized versions. In addition to blacklisted functions, for support reasons, we do not allow any modules that permit arbitrary SQL commands to be run against a Sugar database. Should we find such a module, we will remove it immediately and without warning.
- When integrating with services that make use of SSL or TLS, such as LDAP or SMTP servers, certificate validation is enforced in Sugar's cloud service. Any certificates used must be issued by an industry recognized Certificate Authority with a valid trust hierarchy.
- All inbound entryPoints must be authenticated.
- Outbound HTTP connections must have timeouts under 1 second.
- Batch API access should reuse a session rather than performing a login for every call.
- In Sugar's cloud service, Sugar is deployed with the PHP
- This configuration setting limits which files can be accessed from PHP to a predefined list of directories.
- This is an important setting that helps to keep your data secure.
- A side effect of
open_basediris that the ability for curl to follow HTTP redirects is disabled. Attempts to set
CURLOPT_FOLLOWLOCATIONwill cause PHP failures.
- Sugar's cloud service runs a Linux operating system with a case-sensitive file system. Windows- or OSX-based developers should verify that their customizations function appropriately when case-sensitive file systems are utilized.
- Sugar's cloud service does not allow customers to relay email through SugarCRM SMTP servers. In order to configure your own SMTP servers please refer to the Configuring Your SMTP Server to Work With SugarCloud article.
- All MySQL tables must use the InnoDB storage engine. MyISAM tables are not permitted in order to maintain data integrity.
- File names should only consist of UTF-8 characters. Non-UTF-8 characters in file names are not supported.
- Sugar's cloud service does not enable support for htaccess. As such, no changes to htaccess rules are permitted in Sugar's cloud.
- Scheduled jobs within a cloud instance are limited to a maximum runtime of 30 minutes.
Enforced Configuration Parameters
The following configuration parameters are enforced in Sugar's cloud service for performance and security reasons. Should you require a setting to be temporarily changed on a cloud production environment, you must open a support case. To change any of these default settings on a backup or sandbox environment, you must be a developer with access to the
config.php file. To see a description of the setting as well as other potential values, click on the parameter name in the table below.
In addition to Module Loader, the Package Scanner is also used during the migration procedure. When an on-site instance is migrated to Sugar's cloud, the following procedure is followed:
- Only currently supported versions of Sugar can be migrated to Sugar's cloud service. For the current list of supported software, consult the list of supported versions. If you are running an unsupported version of Sugar, you will need to upgrade to a supported version before providing the required files and database to our team for migration.
- All backups must consist of the MySQL dump and an accompanying file system in TAR format. Detailed instructions for creating backups are located in the Recommended Backup Procedure section of this documentation.
- The customer or partner should open a support case to provision an FTP site to upload the customer's instance to and coordinate the migration process. We require at least seven (7) calendar days' advance notice for a requested migration to ensure the desired date and time can be accommodated. This notice should be provided in the form of a support case.
- When requesting a migration, we ask you to provide the following details so that we can ensure the appropriate resources are allocated to your SugarCloud instance:
- Instance total file size
- Instance total database size
- Total active users in the instance and estimated maximum concurrent users in the instance
- Primary business use(s) for the instance (e.g. sales, call center, marketing campaigns, etc.)
- Integrations installed on the instance
- Description of any external services connecting to the application via API
- Once the FTP account is provided, the instance files and the database should be uploaded at the desired date and time.
- Sugar performs several tasks with the provided files:
- All instance core files are replaced with stock versions.
- Config values located in
./config_override.phpare replaced to reflect values required by Sugar's cloud service. For more information, please refer to the Enforced Configuration Parameters section of this documentation.
- All non-core files are scanned using the latest version of the Package Scanner.
- If any files are found that do not pass the Package Scanner, the migration will be rejected. Upon rejection, the case is updated to indicate the reason for rejection. The customer should correct the issue and upload a new backup.
- If the instance is not on our most recent release and it passes the upgrade health check, the instance will be upgraded to the latest version of Sugar. If the instance does not pass health check, we may require action to be taken to resolve issues blocking the upgrade before finalizing the requested migration.
- Full-text search will be configured and a full system index will be triggered.
Recommended Backup Procedure
Migrating a Sugar instance from on-site to Sugar's cloud service is a straightforward process. Simply download the Sugar Instance Packager from Github and run the following command, replacing
INSTANCE_NAME with the name of your SugarCloud instance (e.g.
SUGARDIR with the directory that contains your on-site Sugar instance:
./packager.php --name INSTANCE_NAME SUGARDIR
Once the packager is done processing, you can view the contents of the zip file to confirm that packaging was successful with the following command, again replacing
INSTANCE_NAME with the name of your SugarCloud instance (e.g.
unzip -l INSTANCE_NAME.zip | less
Logging can dramatically affect performance, and for instances running in Sugar's cloud, we intentionally restrict the verbosity of logging to the fatal level and above to mitigate those performance impacts. This setting means that only fatal and security errors are captured. It is imperative that your integrations do not log anything but fatal and security errors at their respective log level. Please note that the Logger Settings panel in Admin > System Settings is not available for instances hosted on Sugar's cloud service.
Should you require a log level to be temporarily changed on a cloud production environment to debug an issue, you must open a support case. Running instances in a logging mode more verbose than fatal is expressly forbidden in Sugar's cloud environment for performance reasons. Please note that it is also forbidden for integrations to change the log level directly.
Beginning with version 9.1.0, SugarCloud customers can generate PHP error logs and access logs via the SugarCloud Insights page.
File System and Database Size Limits
All instances hosted on Sugar's cloud service are subject to disk utilization limitations. The current base limits per Sugar product are:
- Professional : 15GB
- Sell : 60 GB
- Serve : 60 GB
- Enterprise : 60GB
- Ultimate : 250GB
We measure disk utilization as follows:
- The file system and on-disk database sizes for all instances associated with a given license key are summed together.
- Sandboxes are also counted in this total.
- Should the sum exceed the licensed amount of storage, the customer will be contacted and offered storage uplifts or an opportunity to reduce disk consumption.
Support-authorized contacts with access to the SugarCRM support portal can view storage usage data for their Sugar instance via the Storage Usage dashlet on the support portal home page. For more information regarding the dashlet, please refer to the Using the Support Portal article.
Beginning with version 9.1.0, SugarCloud customers can monitor their instance's database and file system storage usage via the SugarCloud Insights page.
Database Update Requests
SugarCloud customers do not have direct access to the database supporting their instance, and it is forbidden to install any utility which circumvents this restriction. Occasionally, there may be a need for direct database queries to be run against a cloud instance, and if this is needed, please open a support case. When opening a case, please observe the following guidelines for these types of requests:
- It is the responsibility of the customer and/or partner to develop the desired database queries for the Sugar Support team to run.
- Requests should be submitted a minimum of 1 business day before the request needs to be completed. Depending on the volume of database queries that need to be performed, additional lead time may be necessary to complete the request.
- All database queries should be submitted in a .sql file attached as a note to the case, or if larger in size, via an FTP account that will be provided by Sugar Support. Please archive any .sql file larger than 1 MB. We will not accept files hosted on an external FTP account or URL.
- Recurring requests will not be accepted as these requests should leverage our supported APIs to complete.
- Please indicate the nature of the database queries the Sugar Support team is expected to perform:
- UPDATE, INSERT, DELETE, and/or TRUNCATE statements are the only queries the Sugar Support team will perform.
- Please indicate if any of the statements involve table joins as that will require additional analysis to ensure they are optimized and will not impact server performance.
- Sugar's cloud service does not support using custom database triggers or stored procedures, and any requests to perform queries creating these properties will be rejected.
Activities within a cloud instance are expected to be performant and not exceed a maximum number of requests per second to ensure a stable environment. SugarCRM reserves the right to block traffic to a cloud instance when one or both of the following scenarios are impacting the stability of Sugar's cloud environment:
- Traffic in excess of 20 requests per second
- Inefficient requests (e.g. non-optimized database queries, unsupported APIs, etc.)
- SELECT queries will be terminated after 120 seconds
In the event that SugarCRM detects one of the above scenarios impacting your instance, the following actions will be taken:
- Traffic from the offending IP address(es) to Sugar's cloud environment will be temporarily blocked
- A support case detailing the reasons for the restriction will be opened under your account if one does not already exist
- The Sugar Support team will contact you to advise of the temporary traffic restriction and work with you to resolve the issue
- Once you confirm the traffic issue to be remedied, the temporary restriction will be lifted and traffic will be closely monitored to ensure no recurrence of the behavior
In the event that you expect to perform a temporary action which would exceed 20 requests per second or you expect your traffic to exceed this rate on an ongoing basis, we require advance notice of the action as follows:
- A case is created with the following information a minimum of 7 calendar days before the increased activity is to take place:
- Start date and time of the activity and its expected duration
- Direct phone and email contact information for the individual coordinating or performing the activity
- Specific details of activity including advanced agreement on limits for requests per second, concurrency, and the originating IP address(es) of the activity
- Details of any external integrations to be utilized
- During the activity period, SugarCRM staff will monitor the database and web servers for potential issues.
- Should issues arise, our staff will contact the individual performing the activity and ask them to immediately cease.
Load testing of a cloud instance is permitted only if the following conditions are met:
- A case is created with the following information a minimum of 7 calendar days before the load test is to take place:
- Load test date and time
- Direct phone and email contact information for the individual performing the testing
- Specific details of test including advanced agreement on limits for requests per second, concurrency, and the specific workflows to be tested
- Details of any external integrations to be tested
- During the load testing, SugarCRM staff will monitor the database and web servers for potential issues.
- Should issues arise, our staff will contact the individual performing the load test and ask them to immediately cease.
No load testing will be permitted without explicit, written sign-off from Sugar Support. In addition to load testing, you are required to notify us of any expected, significant upticks in general usage, which is defined as an increase of more than 10%.
Penetration testing of a cloud instance is permitted only if the following conditions are met:
- A case is created with the following information a minimum of 7 calendar days before the penetration test is to take place:
- Penetration test date and time
- Direct phone and email contact information for the individual performing the testing
- Agreement to share the results with SugarCRM at the conclusion of the penetration test
- Agreement that the results of the test are bound by our NDA and are non-disclosable to any other parties
- During the penetration testing, SugarCRM staff will monitor the database and web servers for potential issues.
- Should issues arise, our staff will contact the individual performing the penetration test and ask them to immediately cease.
No penetration testing will be permitted without an explicit, written sign-off from Sugar Support. In addition to penetration testing, you are required to notify us of any expected, significant upticks in general usage, which is defined as an increase of more than 10%.
Cloud sandboxes will only be provisioned for customers with valid sandbox licenses. Depending on your Sugar edition, a certain number of sandboxes may already be included. Should you require additional sandboxes, they must be purchased through the orders desk. If your subscription includes a sandbox, we do not automatically provision the sandbox instance. Please file a support case to have a permanent sandbox created for your instance. For more information on SugarCloud sandbox allowances and how to request a cloud-hosted sandbox, refer to the SugarCloud Sandboxes page.
By default, cron jobs are not set to run on sandbox instances to avoid scenarios where the sandbox instance executes a scheduled job (e.g. inbound email retrieval) that should have been processed by the customer's production instance.
As a reminder, the file and database storage used by a sandbox is counted toward a customer's overall cloud storage limit.
For critical events such as major upgrades and maintenance windows, SugarCRM sends an email alert to all administrative users with a valid email address configured in the SugarCloud instance. SugarCloud customers can specify additional email addresses for alerts so that your Sugar partner, IT team members, sales managers, etc. may stay abreast of key events without occupying an administrative license in your instance.
Follow these steps to manage the email addresses that receive critical SugarCloud service notifications:
- Navigate to Admin > Notification Settings.
- Add or remove any email addresses that should receive critical cloud notifications. Do not add email addresses that are already associated with an administrative user's profile in your instance, as they are automatically sent Sugar's cloud notifications.
- Click the Save button.
SugarCRM provides seven days of notice for major upgrades. Major upgrades are any upgrade in which either of the first two digits of the version number will change. In SugarCloud, each seasonal release is considered a major upgrade. We will automatically schedule your instance upgrade within 30 days of a major release. An email is sent out seven days in advance of the upgrade to all configured email addresses as described in the SugarCloud Communications section of this page. If the proposed upgrade date and time are not amenable to your business needs, you may request an alternative day that occurs no later than two months from the release date. Upgrade extensions must be requested by opening a support case. At this time, it is not possible to opt out of an upgrade as we ensure a stable, common environment for all customers hosted on Sugar's cloud service.
Please note that SugarCRM requires all SugarCloud customer instances to run on a supported version of Sugar. When running a supported version, customers may still be required to upgrade to a more recent version of Sugar to remain in Sugar's cloud environment. These upgrade requirements ensure we are able to prevent exposure to known security vulnerabilities and maintain an optimal hosting environment for our customers.
Instances with no configured email addresses set up will not receive prior notice for upgrades. Minor upgrades (i.e. upgrades for which neither of the first two version digits changes), do not trigger a notification.
All upgrades are processed within an 8-hour window depending on where your Sugar instance is hosted:
|Instance Hosting Location||Default Nightly Upgrade Window|
|North America||03:00 - 11:00 UTC|
|Europe||19:00 - 03:00 UTC|
|Australia||10:00 - 18:00 UTC|
Customers may request a custom 8-hour upgrade window by opening a support case.
For more information, please refer to the Upgrading SugarCloud Instances article.
Backup Storage Policy
SugarCRM backs up all production instances on Sugar's cloud service every 24 hours. All active cloud instances are backed up daily, and each backup is retained for 30 days. In addition, backups are taken immediately preceding upgrades and are also retained for a 30-day period. Please note that backups cannot be made available for instances hosted in SugarCRM's demo environment, and daily backups of these instances are not performed.
For the SugarCloud production environment, backups can be made available for you to download from your instance's Backups module at a frequency determined by your edition of Sugar. For more information on the backup limit for your subscription, please refer to the SugarCloud Offerings page.
If a customer either migrates from Sugar's cloud service to an on-site deployment or allows their subscription with SugarCRM to expire, their SugarCloud instance will be archived. Once archived, a final backup of the instance will be retained for a period of 120 days at which point, the instance files and data will be completely deleted. If this instance data is needed within the 120-day timeframe, please open a support case or, if you are no longer a customer, send an email to email@example.com to request the files.
Security Patch and Communication Process
Upon discovering a security vulnerability in the Sugar application, a fix will be developed by our engineering department. Following the successful testing of the fix by our quality-assurance department, a hotfix will be developed. The hotfix deployment process then begins immediately. SugarCRM's commitment is to secure all instances using Sugar's cloud service from a known vulnerability before publicly disclosing the vulnerability.
SugarCRM maintains a standard weekly maintenance window from 00:01 UTC to 09:00 UTC on Sundays. Activities that are performed in this weekly window fall into one of two categories: routine maintenance or platform upgrades.
For routine maintenance which will involve downtime, an email message will be sent to cloud communication recipients of affected instances 3 days prior to the event. Examples of routine maintenance would be operating system or platform patches, server resizing, migrating your SugarCloud instance to a new cloud stack, etc.
For platform upgrades, two email communications will be sent to cloud communication recipients of affected instances. The first communication will be a minimum of 2 weeks before the platform upgrades are initiated in Sugar's cloud. The purpose of this communication is to provide a general window when to expect the upgrade to occur so that any necessary preparations can be made. The second communication will be 3 days prior to the event. Examples of platform upgrades would be upgrading major versions of the components necessary to run Sugar such as MySQL, PHP, Elasticsearch, etc.
Unscheduled Maintenance and Downtime
In extreme circumstances, we may determine that the best course of action to address an issue impacting the stability or security of the SugarCloud requires downtime outside of our weekly maintenance window. In these cases, we make every effort to provide as much advance notice as possible to our customers via email communications and our community. Customers can always check the current SugarCloud server status at http://status.cloud.sugarcrm.com. Details on current status are updated in near real-time.
Last modified: 2019-12-03 20:15:34