I had the incorrect assumption that the pbm cli only needed access to mongo and not additionally the backup storage itself when running
pbm status. It was only after a very long timeout that I ever got a network error.
pbm status --mongodb-uri=mongodb://xxx:yyy@zzz/ Error: get status of backups: get storage: init container: unknown error ensuring container https://xxx.blob.core.windows.net/yyy: -> github.com/Azure/azure-pipeline-go/pipeline.NewError, /mnt/jenkins/workspace/pbm-autobuild-RELEASE/test/percona-backup-mongodb-1.6.1/build/src/github.com/percona/percona-backup-mongodb/vendor/github.com/Azure/azure-pipeline-go/pipeline/error.go:157 HTTP request failed Put "https://xxx.blob.core.windows.net/yyy?restype=container&timeout=1201": dial tcp n.n.n.n:443: i/o timeout
Now that I know this, I’ll apply the network policy that allows this traffic to the pod running my backup check script. The docs say that the pbm cli uses the control collections to get the agent to take actions. If checking the status really does need to talk to the backup storage account, I think the documentation should note that. Though I suppose that is implied here.