CLIでAmazon Workspacesを作成する場合の注意事項

Takuya Shibata

2020.11.02

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

しばたです。
本記事は正確には「WorkSpacesとディレクトリを紐づける際の注意事項」なのですが分かりやすさのためにこんなタイトルにしています。
ちょっと今CLI(AWS Tools for PowerShell)でAD ConnectorおよびWorkSpaces作っていたのですが、その際に何点かハマった点があったのでこの記事で共有します。
使っていたのがAWS Tools for PowerShellだったので記事中もPowerShellのコード例を出しますがAWS CLIを使う場合でも同様の注意が必要となります。

AWS CLIをお使いの方は適宜コード例を置き換えてみてください。
 WorkSpacesとディレクトリを紐づける際の権限についてCLIでWorkSpacesとディレクトリを紐づけるにはRegister-WKSWorkspaceDirectoryコマンドレット(AWS CLIの場合はaws workspaces register-workspace-directory)を使い以下の様に実行します。
$params = @{
    DirectoryId = '<紐づけ対象のディレクトリID>'
    SubnetId = ('<WorkSpacesを展開するサブネットID 1つめ>', 'WorkSpacesを展開するサブネットID 2つめ')
    EnableSelfService = $true
    EnableWorkDoc = $false
}
Register-WKSWorkspaceDirectory @params
当然このコマンドの実行にはそれなりの権限が求められ、権限不足の場合は下図の様なエラーとなります。
ここでは
User <your role> is not authorized to perform: workspaces:RegisterWorkspaceDirectory on resource: arn:aws:workspaces:ap-northe

ast-1:xxxxxxxxx:/
とworkspaces:RegisterWorkspaceDirectoryという見慣れない権限を求められます。

この権限はマネジメントコンソールから追加しようとしても「そんな権限は無い」と警告されるうえに、
強引に設定しても結局権限エラーのまま別のメッセージが表示されてしまいます。
Register-WKSWorkspaceDirectory : You do not have sufficient access to perform this action. For more information, see https://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-access-control.html.
WorkSpacesの管理に関わる権限はこちらで紹介されている
Identity and Access Management for Amazon WorkSpaces
に詳細が記載されており、この内容に従う必要があります。

例えばWorkSpacesの管理に関わる全権が必要な場合は
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "workspaces:*",
        "ds:*",
        "iam:PassRole", 
        "iam:GetRole", 
        "iam:CreateRole", 
        "iam:PutRolePolicy", 
        "kms:ListAliases",
        "kms:ListKeys",
        "ec2:CreateVpc", 
        "ec2:CreateSubnet", 
        "ec2:CreateNetworkInterface", 
        "ec2:CreateInternetGateway", 
        "ec2:CreateRouteTable", 
        "ec2:CreateRoute", 
        "ec2:CreateTags", 
        "ec2:CreateSecurityGroup", 
        "ec2:DescribeInternetGateways",
        "ec2:DescribeSecurityGroups",
        "ec2:DescribeRouteTables", 
        "ec2:DescribeVpcs", 
        "ec2:DescribeSubnets", 
        "ec2:DescribeNetworkInterfaces", 
        "ec2:DescribeAvailabilityZones", 
        "ec2:AttachInternetGateway", 
        "ec2:AssociateRouteTable", 
        "ec2:AuthorizeSecurityGroupEgress", 
        "ec2:AuthorizeSecurityGroupIngress", 
        "ec2:DeleteSecurityGroup", 
        "ec2:DeleteNetworkInterface", 
        "ec2:RevokeSecurityGroupEgress", 
        "ec2:RevokeSecurityGroupIngress",
        "workdocs:RegisterDirectory",
        "workdocs:DeregisterDirectory",
        "workdocs:AddUserToGroup"
      ],
      "Resource": "*"
    }
  ]
}
が必要とされており、結局workspaces:*、ds:*な権限が必要となります。
 workspaces_DefaultRole IAMロールの事前準備について必要な権限を設定し再度Register-WKSWorkspaceDirectoryを実行しても今度は以下の様に「workspaces_DefaultRole IAMロールが無い」と怒られてしまいます。
このworkspaces_DefaultRoleロールはWorkSpacesのサービスにデフォルトで設定されるロールであり、マネジメントコンソールから手作業で紐づけ作業を行う場合は裏側で自動作成されるロールになります。

CLIから紐づけを行う場合は事前に作成しておく必要があります。
workspaces_DefaultRoleロールの作り方についても先ほどのドキュメントに記載されています。
Creating the workspaces_DefaultRole Role
詳細についてはドキュメントをご覧いただきたいのですが、大事な点としては
WorkSpacesのサービスが利用する権限のため、信頼されたエンティティを「workspaces.amazon.com」とする
AmazonWorkSpacesServiceAccess、AmazonWorkSpacesSelfServiceAccessの2つのマネージドポリシーをアタッチする
になります。

参考としてPowerShellから作る手順を紹介しておきます。
# まずはロールを作成
$params = @{
    RoleName  = 'workspaces_DefaultRole'
    Description = 'WorkSpaces default role created by user. (not by console!)'
    AssumeRolePolicyDocument = 
@'
{
    "Version": "2012-10-17",
    "Statement": [
        {
        "Effect": "Allow",
        "Principal": {
            "Service": "workspaces.amazonaws.com"
        },
        "Action": "sts:AssumeRole"
        }
    ]
    }
'@
}
$role = New-IAMRole @params
# 2つのマネージドポリシーをアタッチ
Register-IAMRolePolicy -RoleName $role.RoleName -PolicyArn 'arn:aws:iam::aws:policy/AmazonWorkSpacesServiceAccess'
Register-IAMRolePolicy -RoleName $role.RoleName -PolicyArn 'arn:aws:iam::aws:policy/AmazonWorkSpacesSelfServiceAccess'
 補足 : ロール作成権限に関してworkspaces_DefaultRoleロールを作成するにはiam:CreateRoleとiam:AttachRolePolicyが必要になりますが、先述のドキュメントにはiam:AttachRolePolicyに対する記述はありませんので、必要に応じて適宜権限を与えておく必要があります。
 マネジメントコンソールから workspaces_DefaultRole を作る場合との微妙な差異最後にworkspaces_DefaultRoleロールについて、ドキュメントで要求されるロールとマネジメントコンソールから自動作成された場合で微妙に権限が異なるのでその差異について紹介しておきます。
 ドキュメントが要求する権限まずはドキュメントが要求するAmazonWorkSpacesServiceAccess、AmazonWorkSpacesSelfServiceAccessの2つのマネージドポリシーの権限は以下の通りとなっています。
 AmazonWorkSpacesServiceAccessAmazonWorkSpacesServiceAccess
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "ec2:CreateNetworkInterface",
                "ec2:DeleteNetworkInterface",
                "ec2:DescribeNetworkInterfaces"
            ],
            "Effect": "Allow",
            "Resource": "*"
        }
    ]
}
 AmazonWorkSpacesSelfServiceAccessAmazonWorkSpacesSelfServiceAccess
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "workspaces:RebootWorkspaces",
                "workspaces:RebuildWorkspaces",
                "workspaces:ModifyWorkspaceProperties"
            ],
            "Effect": "Allow",
            "Resource": "*"
        }
    ]
}
 マネジメントコンソールから自動生成される権限次にマネジメントコンソールから自動生成された場合ですが、
上図の様にマネージドポリシーではなく
SkyLightServiceAccess
SkyLightSelfServiceAccess
の2つのインラインポリシーがアタッチされています。

これらの権限は以下の通りです。
 SkyLightServiceAccessSkyLightServiceAccess
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "ec2:CreateNetworkInterface",
                "ec2:DeleteNetworkInterface",
                "ec2:DescribeNetworkInterfaces",
                "galaxy:DescribeDomains"
            ],
            "Effect": "Allow",
            "Resource": "*"
        }
    ]
}
 SkyLightSelfServiceAccessSkyLightSelfServiceAccess
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "workspaces:RebootWorkspaces",
                "workspaces:RebuildWorkspaces",
                "workspaces:ModifyWorkspaceProperties"
            ],
            "Effect": "Allow",
            "Resource": "*"
        }
    ]
}
 両者の差異両者を比較するとこの様になります。


ドキュメントが要求するポリシー
マネジメントコンソールから自動生成されるポリシー
差異


AmazonWorkSpacesServiceAccess
SkyLightServiceAccess
SkyLightServiceAccess のみ galaxy:DescribeDomains が存在

AmazonWorkSpacesSelfServiceAccess
SkyLightSelfServiceAccess
差異なし

内容はほぼ同一ですが、SkyLightServiceAccessにのみgalaxy:DescribeDomainsという謎のアクションを許可する設定が組み込まれています。
そもそもgalaxy:というサービスが何なのかは完全に謎ですが一般ユーザーが気にする類のものではないと思われますのでどちらを選んでも問題ないでしょう。

ただ「作り方により差異がある」点は知っておくとトラブルシュート等の場合で役に立つこともあるかと思います。
 終わりに以上となります。
CLIからWorkSpaces環境を構築すること自体がレアケースかもしれませんが、この記事の内容がこれからCLIを試してみる方の役に立てば幸いです。

CLIでAmazon Workspacesを作成する場合の注意事項

WorkSpacesとディレクトリを紐づける際の権限について

workspaces_DefaultRole IAMロールの事前準備について

補足 : ロール作成権限に関して

マネジメントコンソールから workspaces_DefaultRole を作る場合との微妙な差異

ドキュメントが要求する権限

AmazonWorkSpacesServiceAccess

AmazonWorkSpacesSelfServiceAccess

マネジメントコンソールから自動生成される権限

SkyLightServiceAccess

SkyLightSelfServiceAccess

両者の差異

終わりに

関連記事

主なカテゴリ

AWS

おすすめ

プロダクト

コンテンツ

お問い合わせ

運営会社

ドキュメントが要求するポリシー	マネジメントコンソールから自動生成されるポリシー	差異
AmazonWorkSpacesServiceAccess	SkyLightServiceAccess	SkyLightServiceAccess のみ galaxy:DescribeDomains が存在
AmazonWorkSpacesSelfServiceAccess	SkyLightSelfServiceAccess	差異なし