The fidelity of cloud security posture information and cloud compliance results presented in CloudGuard CSPM (formerly "Dome9") is dependent on effective/unbroken access to the cloud platform APIs that Customers authorize CloudGuard to use during the cloud account onboarding process. In order to completely refresh every data point in every CloudGuard cloud resource entity-model, most of these APIs are called several times (first to enumerate the population of protected resources, then to collect progressively finer-grained details about individual resource-instances) during each CloudGuard data refresh cycle -- which is currently defined as 30 minutes for most cloud resources. If any one of these API calls cannot be completed due to permission errors, the corresponding data points will not be refreshed, and as a result the state of cloud resources as represented in CloudGuard may cease to accurately reflect the current state of those resources in their cloud-native environment. The CloudGuard service will retry any API call that returns a "permission denied" error a few times, to limit sensitivity to congestion or other highly transient access issues, but the number of retries is quite limited by design, to prevent more durable Customer permission problems from triggering a cascade of unproductive CloudGuard API calls. Currently, this limit is set at three consecutive API call permission-denied errors (note: current practice is sometimes referred to as the "three strikes and you're out" mechanism).
Once this limit has been reached, the CloudGuard CSPM service will discontinue any further attempts to access that API until the Customer signals the CloudGuard service that the underlying cause of the permission denied errors has been eliminated, and so it once again safe for the CloudGuard service to attempt to access that API.**
The existence of a breaking permission error is indicated by the appearance of a warning icon in the "status" column on the CloudGuard "Accounts" management page (https://secure.dome9.com/v2/cloud-account/index). Additional details about exactly which API calls have been terminated, and which cloud resources may be be misrepresented in CloudGuard due to the loss of access to current cloud resource metadata can be found in the "Detailed View" for the corresponding cloud account (e.g., https://secure.dome9.com/v2/cloud-account/<platform>/<d9-cloud-account-id>).
Once the Customer has identified and corrected the underlying cause of the "missing permission" errors,** they should signal the CloudGuard service to resume attempts to use the discontinued API calls by clicking the "VALIDATE PERMISSIONS" button (at the individual cloud account-level, or if appropriate on the Cloud Accounts management page). Each time that button is triggered causes the number of "strikes" stored for that API to be decremented by one; thus for example, clicking "VALIDATE PERMISSIONS" three times will restore the API's stored state to zero "strikes."
**IMPORTANT: clicking "VALIDATE PERMISSIONS" does not (CANNOT) fix the underlying factors that trigger "missing permission" errors.
Since CloudGuard was consciously designed to deliver services without imposing a requirement for Customers to extend risky, high-privilege access permissions to a "third-party," it is not possible for the CloudGuard CSPM service to actually "fix" a permission problem (or, in all but extremely narrow circumstances, to modify any aspect of a Customer's cloud environment in any way). Additionally, since a "missing permission" error may arise from a variety of different circumstances (e.g., the presence of a preemptive "Deny" policy at some sub-account/individual cloud resource level, or at a supra-account/Organizational level), and because such errors tend to disrupt/distort any diagnostic information that the CloudGuard service might be able to collect under normal operating conditions, the most useful guidance that CloudGuard can provide for identifying and correcting such problems will be found in the Detailed View page for the affected cloud account.
