2

私は、Service FabricクラスタのVMスケールセットを作成し、キーボールのVMといくつかの秘密を関連付けるARMテンプレートを使用しています。私はそれがVMを表示され、keyvaultが同じ地域に存在している必要がありますか、私はこのようなエラーが出ることを今朝発見:別の領域でkeyvaultを使用してスケールを設定しました

New-AzureRmResourceGroupDeployment : 9:24:55 AM - Resource Microsoft.Compute/virtualMachineScaleSets 'StdNode' failed with message '{ "status": "Failed", "error": { 
    "code": "ResourceDeploymentFailure", 
    "message": "The resource operation completed with terminal provisioning state 'Failed'.", 
    "details": [ 
     { 
     "code": "KeyVaultAndVMInDifferentRegions", 
     "message": "The Key Vault https://obscured.vault.azure.net/secrets/secretname/1112222aa31c4dcca4363bb0013e9999 is located in location West US, which is different from the location of the VM, northcentralus. " 
     } 
    ] } }' 

これは人工的な制限のように感じていると私にとって大きな問題です。私はすべての私の秘密を配備し、すべての私の配備からそれらを利用する中央のキーボールを持っていたい。世界中の地域で私の秘密を複製することはばかばかしいようで、非常にエラーが発生する傾向があります。地域間で秘密を得るには、ここで重要な問題はないはずです。だから、これの背後にある理由は何ですか?それは変わるでしょうか?

Azure Scale Setsチームの誰かがこれに色を付けたいですか?

答えて

0

リージョン境界を強制する理由は、リージョン間の依存関係を持つアーキテクチャをユーザーが作成できないようにするためです。

このように設計されたアプリケーションでは、japaneastデータセンターの機能停止により、JapanWestのVMSSesがスケールアウトできなくなります。

地域の分離は、クラウドベースのアプリケーションの重要な設計原則であり、できる限りユーザーが悪い選択をしないようにしたいと考えています。

クロスサブスクリプションの参照を許可しない理由は、悪意のあるユーザーが他のユーザーの秘密にアクセスするための権限昇格メカニズムとしてCRPを使用しないようにするための重要な最終ステップです。 これもARMではこれを防ぐ他のメカニズムがありますが、構成に基づいています。

+2

ここで私はあなたの意図を理解していますが、それは私にとっては過度に制限的だと感じています。通常は正しい方向であることをアーキテクチャに導くことは魅力的です。デベロッパーは、Azureの導入方向ではないと予期しない方法でソリューションを設計することを防ぎます。私の場合は、 1つのキーボートは悪い設計ですが、この制限があると、2〜3つのボールトについて言えば、私の配置の中にその使い方を広げることさえできません。私は、すべての地域展開でこの機密データを複製する必要があります。これのファンではありません。 – BrettRobi

+0

私は@BrettRobiに同意します。消費者は、単一または地域固有のKeyVaultを持つかどうかを決定する必要があります。この制限により、消費者は複雑さと潜在的なセキュリティ侵害を加える不必要なロジックを作成することになります。なぜこれはストレージアカウントのようなAzure Resourcesには当てはまりませんか? – ksiomelo

+0

ここでBrettと同意します。制限が解除されるのを見たいと思います。ある時点で、多くの重要な格納域に散在する秘密の追跡/管理の複雑さが増しすぎるため、開発者は領域ごとに鍵格納場所を持つ必要はありません。 –

関連する問題