2017-08-16 11 views
1

私のCloudFormation Yamlテンプレートで!Sub関数を使用しています。オブジェクトのプロパティ値として使用すると、それは私のために動作しますAWSクラウドフォーメーションAWS :: Serverless :: Function Policies内のSub&!Ref関数

Object: 
    Property1: !Sub some-value-with-a-${variable}-in-it 

変数の値が期待どおりに置き換えられます。

しかし、私は、文字列の配列

Array: 
    - !Sub some-value-with-a-${variable}-in-it 

単に無視されることを配列要素の要素で!サブ機能を使用する方法を見つけ出すことはできません。

これは、AWS :: Serverless :: Functionタイプのリソースを作成するSAMテンプレートのコンテキストでこれを試しています。ポリシープロパティは、文字列の配列を取ることができます!の

lambda: 
    Type: AWS::Serverless::Function 
    Properties: 
    CodeUri: api 
    FunctionName: !Sub api-${MyStageName} 
    Handler: Lambda:Api.Function::HandleAsync 
    Runtime: dotnetcore1.0 
    Policies: 
    - AWSLambdaBasicExecutionRole 
    - !Sub arn:aws:iam::${AWS::AccountId}:policy/some-policy 
    - arn:aws:iam::123456789:policy/another-policy 

サブ機能は、この例ではFunctionNameプロパティで動作します。しかし私は、作成したロールに添付された2つのポリシー(AWSLambdaBasicExecutionRolearn:aws:iam::123456789:policy/another-policy)で終わるだけです。 !Sub関数を含むものは無視されます。

私は新しい行に機能を置くようなオプションを試してみました:

Array: 
    - 
    !Sub some value with a ${variable} in it 

誰でも助けることができますか?

更新

@Tomメロは、私は私の質問を調整しているので、これは、アレイ上の問題ではないことを指摘しました。

詳しい調査の結果、それがまさに雲の形成の問題ではありません明らかにしたが、AWS::Serverless::Functionリソースタイプに非常に具体的、かつにおける内Policiesプロパティました。私はそれがPoliciesプロパティは非常に柔軟であるという事実とは何かを持っている疑いがありますそれが受け入れられるものである。ポリシー名やArnを参照する文字列を受け入れることができ、新しいポリシーを記述するポリシー文書を受け入れることもできます。私はそれが機能をサポートすることができないことを意味すると思う。

+0

'!Sub'を配列項目またはマッピング値と使用しても違いはありません。これはバグと思われ、そのように報告されるべきです。私は '!Sub'の後にスカラーを引用しようとします。多分それはパーサのバグです、もしそうなら、それは回避策かもしれません。 – flyx

+0

お返事ありがとうございます。引用が機能しなかったので、バグを記録しようとします –

+0

問題が作成されました:https://forums.aws.amazon.com/thread.jspa?threadID=261756 –

答えて

1

明らかに、要素の配列内の!Sub関数には何も問題はありません。

私はCloudformation上で、次のスタックを作成しようとしましたし、それが働いた:

AWSTemplateFormatVersion: '2010-09-09' 
Description: 'IAM Roles Template' 

Parameters: 
    ArnBase: 
    Type: String 
    Default: arn:aws:iam::aws:policy/ 
    AWSLambdaFullAccess: 
    Type: String 
    Default: AWSLambdaFullAccess 
    AmazonSESFullAccess: 
    Type: String 
    Default: AmazonSESFullAccess  

Resources: 

    LambdaRole: 
    Type: AWS::IAM::Role 
    Properties: 
     AssumeRolePolicyDocument: 
     Version: "2012-10-17" 
     Statement: 
      Effect: Allow 
      Principal: 
      Service: lambda.amazonaws.com 
      Action: sts:AssumeRole   
     Policies: 
     - 
      PolicyName: CloudFormationFullAccess 
      PolicyDocument: 
      Version: "2012-10-17" 
      Statement: 
       - 
       Effect: "Allow" 
       Action: "cloudformation:*" 
       Resource: "*"  
     ManagedPolicyArns:   
     - !Sub ${ArnBase}${AWSLambdaFullAccess}   
     - !Sub ${ArnBase}${AmazonSESFullAccess} 
     - !Sub arn:aws:iam::${AWS::AccountId}:policy/CustomAmazonGlacierReadOnlyAccess 

いずれかSAMを使用して動作する必要があることを...

+0

それは面白いです。それを支配してくれてありがとう。私の質問はより具体的にする必要があるように見えます。たぶんそれはSAMか、Serverless Functionタイプのポリシープロパティかもしれません。私はさらに調査します。 –

0

回避策

AWS::Serverless::Functionリソースタイプには、いくつかの方法をサポートしていますアクセスの設定。

  1. Policiesプロパティで直接ポリシーを参照し、そのポリシーを持つロールをフレームワークに作成させます。
  2. Roleプロパティは、すでにポリシーを含むロールを参照できます。

私はオプション1を使用していましたが、オプション2は!Sub機能の問題を回避する方法であることがわかりました。

AWS::IAM::Roleを使用してポリシーを明示的に作成するということは、ManagedPolicyArnsプロパティ内で!Sub機能を使用できることを意味します。例:

role: 
    Type: AWS::IAM::Role 
    Properties: 
    ... 
    ManagedPolicyArns: 
     - !Sub arn:aws:iam::${AWS::AccountId}:policy/some-policy 
    ... 
lambda: 
    Type: AWS::Serverless::Function 
    Properties: 
    ... 
    Role: !GetAtt role.Arn 
    ... 
関連する問題