簡體   English   中英

AWS:嘗試將指標從 EC2 推送到 CloudWatch 時出現身份驗證問題

[英]AWS: Authentication issues trying to push metrics to CloudWatch from EC2

我正在嘗試設置一個 EC2 (RHEL7) 實例,以使用http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/mon-scripts.html 中所述的 perl 腳本將指標推送到 cloudwatch

我收到一條 HTTP 狀態 400 消息“請求中包含的安全令牌無效”

實例配置文件與附加了以下策略的實例相關聯:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "cloudwatch:PutMetricData",
                "cloudwatch:GetMetricStatistics",
                "cloudwatch:ListMetrics"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeTags"
            ],
            "Resource": "*"
        }
    ]
}

我從實例元數據中提取AWSAccessKeyIdAWSSecretKey ,如下所示:

ROLE=$(curl http://169.254.169.254/latest/meta-data/iam/security-credentials/)
CRED=$(curl http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE)

AWSAccessKeyId=$(sed '/AccessKeyId/!d; s/.*:\ \+"\(.\+\)",/\1/g' <<< "$CRED")
AWSSecretKey=$(sed '/SecretAccessKey/!d; s/.*:\ \+"\(.\+\)",/\1/g' <<< "$CRED")

...當我檢查它們時,上述變量中​​設置的值是正確的...

我正在運行腳本以按如下方式推送到 cloudwatch(使用存儲在上面變量中的憑據):

./mon-put-instance-data.pl --mem-util --verbose --aws-access-key-id  $AWSAccessKeyId --aws-secret-key $AWSSecretKey

任何想法為什么拒絕我的憑據?

提前致謝

如果您使用的是 IAM 配置文件,則無需輸入腳本調用的憑據。 從您的呼叫中刪除訪問密鑰和秘密密鑰。

./mon-put-instance-data.pl --mem-util --verbose

是的。 你們都是對的 - 如果您沒有指定並且似乎有效,它會自動獲取角色信用。

不知道為什么它不能通過手動設置信用來工作,但我可以查看 perl 腳本來很容易地解決這個問題。

感謝您的幫助。

文檔

以下示例假定您提供了 IAM 角色或 awscreds.conf 文件。 否則,您必須使用 --aws-access-key-id 和 --aws-secret-key 參數為這些命令提供憑據。

作為出現錯誤時的一個選項:

錯誤:無法調用 CloudWatch:HTTP 400。消息:請求中包含的安全令牌無效。

該腳本使用配置文件(例如,使用錯誤的憑據):

aws-scripts-mon/awscreds.conf

因此,必須提供 IAM 角色或awscreds.conf--aws*參數。 並且 IAM 角色具有正確的權限

cloudwatch:PutMetricData
cloudwatch:GetMetricStatistics
cloudwatch:ListMetrics
ec2:DescribeTags

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM