C# AWS SDK SecurityTokenServiceClient.AssumeRole, возвращающий «SignatureDoesNotMatch» 403 запрещено

Question

Я внедряю интеграцию AWS S3 с C# AWS SDK в среде разработки, и все идет хорошо. Часть требования заключается в том, что IAM AccessKey и SecretKey вращаются, а учетные / конфигурационные файлы сохраняются или кэшируются, а также есть роль, которую следует принять в этом процессе.

У меня есть метод, который возвращает учетные данные после инициализация AmazonSecurityTokenServiceClient с помощью AccessKey, SecretKey и RegionEndpoint, форматирование AssumeRoleRequest с RoleArn, а затем выполнение запроса:

using (var STSClient = new AmazonSecurityTokenServiceClient(accessKey, secretKey, bucketRegion))
{
    try
    {
        var response = STSClient.AssumeRole(new AssumeRoleRequest(roleARN));

        if (response.HttpStatusCode == System.Net.HttpStatusCode.OK) return response.Credentials;
    }
    catch (AmazonSecurityTokenServiceException ex)
    {
        return null;
    }
}

Это упрощается, поскольку реальная реализация проверяет переменные учетных данных, и т. д. c .. И он соответствует AWS примерам кода разработчика (хотя я больше не могу найти ссылку на эту страницу).

Это работает в dev просто отлично. Переместив это в QA env с новыми AWS учетными данными, которые, я уверен, были настроены в том же процессе, что и учетные данные dev, я теперь получаю исключение при вызове AssumeRole.

Фактический метод AssumeRole не включает документацию о том, что он вызовет это исключение, а только тот, который он вызывает. StatusCode: 403 Forbidden, ErrorCode: SignatureDoesNotMatch, ErrorType: Sender, Message «Рассчитанная нами подпись запроса не соответствует предоставленной вами подписи ....».

Вещи, которые я исключил:

• Ключи являются правильными и не содержат экранированных символов (/) или пробелов в начале / конце

• регион ведра правильный us-west-2

• sts регион авторизации us-east-1

• SignatureVersion равно 4

Переключение обратно на устройство Ключи работают, но это не удобное для производства решение. В конечном итоге я не буду отвечать за ключи или учетную запись Aws для их создания. Я связывался с ИТ-администратором, который создал учетные записи / ключи / роли, и заверил меня, что они созданы так же, как я создал учетные записи / ключи / роли разработчиков (это было согласованным процессом до разработки).

Доступ к предоставленным учетным записям / ключам / ролям можно получить через CLI или веб-консоль, поэтому я могу подтвердить, что они работают и активны. Я усердно старался не создавать какие-либо создаваемые CLI учетные или конфигурационные файлы, к которым sdk мог бы обращаться по умолчанию.

Любые мысли и предложения приветствуются.