Skip to main content
With the cloud.policy setting on, PMG applies the cloud policy of your tenant: its block entries, its trust entries and its dependency cooldown. Your security admin changes the policy in SafeDep Cloud, and PMG gets the change with no new config on each machine.
The cloud policy needs the SafeDep Cloud Team or Enterprise plan. See pricing. Without cloud.policy, PMG works as before and blocks malicious packages with no account.

​
Turn on the cloud policy on one machine

  • pmg cloud login stores the tenant ID and an API key of the tenant. PMG can also read them from the SAFEDEP_TENANT_ID and SAFEDEP_API_KEY environment variables.
  • cloud.policy applies only when cloud.enabled is true.
  • pmg cloud sync fetches the policy at once.
  • pmg config set adds cloud.policy to a config file that an older PMG wrote. If the command prints key not found, the file has no cloud section. Run pmg setup install to add the missing keys of the PMG template to your config file, then run pmg config set again. You can also add the key by hand with pmg config edit.
Then check the state:
The cloud policy check names the tenant, the revision that PMG applied and the age of the cache. It warns when no cache exists yet, when the cache is more than 7 days old, when PMG rejected a policy, and for each field that PMG does not apply.

​
Turn on the cloud policy with MDM

On an endpoint with a managed config file, users cannot change the PMG config. Set both keys in the managed config file:
To turn off all cloud content on a managed endpoint, set cloud.policy: false in the managed config file. Under global_lockdown: true, the cloud policy does not change a key that the managed config file sets. So keep each key that the cloud policy must manage out of that file. See Deploy PMG with MDM.

​
What PMG fetches

PMG fetches the resolved policy of the endpoint. It holds the package rules that apply to the endpoint and the dependency cooldown. PMG sends the labels reported/os and reported/arch with each fetch, so a policy override can select endpoints by operating system or CPU architecture. PMG fetches the policy in the background after each command, also after a command that PMG blocked. It fetches at most once every 5 minutes, also when cloud.auto_sync.enabled is false. pmg cloud sync fetches at once. The persistent proxy applies a new policy with no restart. PMG keeps the policy in the cloud-policy/ folder of its config folder. Under sudo, PMG reads the cache of the user who ran sudo first. On a short-lived CI runner, run pmg cloud sync before the first install. A new runner has no cache, so it applies only the PMG config until the first fetch.

​
Offline and failed fetches

PMG never drops the cloud policy because it is offline. It keeps the last policy that it applied until a newer one arrives. A fetch that fails keeps the cache. When you log out, PMG keeps the last policy. PMG drops a trust entry at its expiry, also with no network.

​
Which settings the cloud policy changes

A trust entry of the policy never skips the malware analysis and never allows verified malware. See Package Rules.

​
What a block looks like

A block entry of the cloud policy stops the install with a message that names the rule and the revision. This example comes from the PMG tests:
With cloud.enabled on, PMG syncs each decision of the cloud policy to your tenant. Your security admin can list them with safedep policy decision list. See Explain a Decision.

​
Known gaps

PMG keeps the policy cache in the folder of the user, so a user can change the cache on a laptop. For each gap of this release, see Cloud Policy Limits.

​
Next steps

Cloud Policy

What the cloud policy controls and who can change it.

Hold Back Newly Published Versions

The dependency cooldown of PMG.

Deploy PMG with MDM

Ship the managed config file to a fleet.

PMG configuration

The config reference in the PMG repository.