Timezone seems right. I’ll look into the permissions.
Is there a way to force a discovery rather than waiting the defined interval time?
But also based on the error, it says “GetAvailableRegions failed”. Is that a different AWS permissions?
2020/04/02 21:45:02 - [debug] AWS Full Discovery for ‘xxxxx’ GetAvailableRegions failed with error: AuthFailure: AWS was not able to validate the provided access credentials
In order to force the discovery, you may recycle the BES Plugin Portal service as first discovery happens right after starting.
AWS plugin needs ec2:Describe* permissions, which includes ec2:DescribeRegions, so if your user has that you shouldn’t be getting that error on GetAvailableRegions.
If you want to take advantage of a predefined AWS policy, AmazonEC2ReadOnlyAccess has everything the AWS plugin needs (and slightly more).
I looked at my IAM role and it does have ReadOnly policy with EC2 listed. I created HCL CS0106188 to investigate.
I think my issue is that just to test, I was using my IAM role that uses a session token, but the Cloud plugin doesn’t allow for token. So I need to get credential that don’t require a session token.
Correct, the AWS plugin won’t support the temporary security credentials + security (session) token generated when assuming an IAM role.
AWS plugin must be configured with an Access key ID / Secret access key pair associated to an IAM user.
I will make sure this is properly explained in BigFix 10 documentation.
Why does the BES property “BES Client Version” show “10.0.0.133” from a Cloud Plugin instance in Amazon when there is no bigfix agent installed?
In case of a proxied computer that version is the version of the Plugin Portal that is handling the computer. This behavior has been inherited from the Proxy Agent.
The reason behind this design choice is that the Plugin Portal (or the Proxy Agent) processes relevance expressions on behalf of the proxied computers, and so its version tells about the relevance capabilities of the proxied computers.
thanks for the info.
The Azure service principal must be assigned the “API Management Service Reader Role”.
UPDATE: The Azure service principal must be assigned the built-in “Reader” role.
Thanks. Please add this to the documenation.
The AWS Cloud Plugin has an Advanced Setting of Proxy URL, but I don’t see that in the Azure Cloud Plugin settings. Was that just missed or is there a reason why the Azure plugin doesn’t allow to use a proxy?
It is possible to have the Azure plugin go through a proxy, but it works differently from AWS. Below information is going to be part of the official BigFix 10 documentation shortly:
How to configure a proxy for Microsoft Azure plugin
In order to have the Microsoft Azure plugin go through a proxy, it is necessary to configure the proxy at system level using the http_proxy and https_proxy environment variables.
Based on this error do you think this is a proxy issue?
2020/04/14 19:39:16 - [debug] Getting Resource Groups
2020/04/14 19:48:46 - [debug] Azure Full Discovery for 'xxxxx' failed getting Resource Groups with error: azure.BearerAuthorizer#WithAuthorization: Failed to refresh the Token for request to https://management.azure.com/subscriptions/xxxxx/resourcegroups?api-version=2019-05-01: StatusCode=0 -- Original Error: adal: Failed to execute the refresh request. Error = 'Post https://login.microsoftonline.com/xxxxx/oauth2/token?api-version=1.0: dial tcp 40.126.0.69:443: i/o timeout'
2020/04/14 19:48:46 - [error] Refresh all: Error occurred while scanning provider with credentials set 'xxxxx': azure.BearerAuthorizer#WithAuthorization: Failed to refresh the Token for request to https://management.azure.com/subscriptions/xxxxx/resourcegroups?api-version=2019-05-01: StatusCode=0 -- Original Error: adal: Failed to execute the refresh request. Error = 'Post https://login.microsoftonline.com/xxxxx/oauth2/token?api-version=1.0: dial tcp 40.126.0.69:443: i/o timeout'
2020/04/14 19:48:46 - [info] Refresh all: Discovery returned 0 unique devicesI’m not able to say, I think it would be good to open a support case for this issue as troubleshooting will likely require logs and other diagnostics elements.
fixed by setting a system variable in windows called http_proxy and https_proxy and then setting them with my webproxy URL. After a reboot, the azure plugin was able to import VM guests.
In the Azure case, the previously mentioned role is not enough, the service principal must be assigned the built-in “Reader” role. We updated the requirement in the “Installing cloud plugins” documentation page accordingly.
Can you please share the screen shots how it set, I am also facing same problem & already tried setting up system variables for http_proxy & https_proxy but no luck.
I know longer have this deployed so I can’t provide a screenshot. But for me I went into Windows environment settings and created to system variables http_proxy and https_proxy Then after a reboot the azure cloud plugin worked.
OK, how you put the value in it, like URL https:\x.x.x.x:8080 or just IP
I tried in both ways but not still not working for us.
i think the variable value was just “<proxy_fqdn:port>”