https://worldofeuc.com logo
Join Slack
Powered by
With Citrix MCS CMI (Core Managed Instances) what ...
# aws-workspaces
l
With Citrix MCS CMI (Core Managed Instances) what is the minimum required IAM role for the VDAs?
s
The 'Action' section is familiar to anyone that knows the architecture of MCS deployed instances
l
Quickly looking at the doc, that appears to be what the cloud connector would need - which we have in place. I was referring to the VDAs (the created VMs). It seems odd that I would need to grant a service linked role to every VM to be able to start, stop, delete volumes, and terminate instances. Are you saying that EVERY VDI that gets created needs that service linked role? Eesh
s
Not the instances, I wasn't referring specifically to the VDAs
l
Oh, that was what my inital question asked.
s
Copy code
This service linked role provides administrative access to Amazon WorkSpaces to manage EC2 instances in your AWS account.
The service uses this role to manage the VDAs
l
Yes, I was aware of that before I read the AWS documentation you linked. My question was, and still is, in reference to the VDAs themselves.
s
Why would the VDAs need roles?
I should say, from an AWS perspective, the question is confusing
The service needs a role to interact with the desktops, but desktop don't interact that way with the service
The whole purpose of Core Managed Instances is to give the VDI vendor the managed service over the instances
so if they make a call to our API, the service assumes the role to execute functions
l
If I can provision the VDAs with no IAM role at all, then that would obviously be best. I was under the assumption (perhaps incorrectly) that the instances needed some kind of IAM role. I'll see if I can remove the GENERIC-EC2 role that our org has that we currently have applied and make sure the VMs all function as expected. They are currently inheriting it from a launch template that has it specified, and that was chosen as we knew we didnt want the VDIs to have the service linked role.
s
We never included an option for WorkSpaces instances to be provisioned with a IAM Role much to the disappointment of developers who want to assume the machine IAM Role to interact with other AWS services, for instance
AppStream 2.0 has it, and it's often used for instance to access S3 buckets
otherwise, the user would have to authenticate and assume an IAM Role to perform those actions, which is just extra work
In this case, because the WorkSpaces service needs to make API calls to the EC2 instances, that is why it's a service-linked role
but the EC2 instances themselves? I mean, the VDA software is making calls from the guest OS
nothing to do with AWS
it's all done within the private subnets deployed in your VPC over the Windows TCP/IP stack
If the Cloud Connector wants to interface with the WorkSpaces service (middle man), then that's a different path
and when the WorkSpaces service receives the command, it assumes the service-linked role to execute it on the EC2 instance
Hope that makes sense
l
It does - I think the issue is that my peer and I were under the mistaken impression that "some" IAM Role was needed on the VDAs - if we can leave it with none, we'll be much happier. It also makes sense as the VDAs are the VMs user work interactively from, they shouldnt need any AWS role, especially delegated to the machine
s
Let me know where the documentation needs updating
I'll push it up
l
Nah, this was just our noobness in AWS showing. Thanks for straightening us out.
s
no problem
l
One item we did find - but this is probably more on the Citrix side than AWS. We have VPC endpoints, and in each endpoint, the policy typically states the service, e.g. ec2:* on the EC2 endpoint, and EBS:* on the ebs-endpoint. we kept having issues because it appears that the API call that Citrix does, uses the EBS endpoint, but it was doing an EC2:Createtag. To get it to work, we had to allow EC2:* on the ebs-endpoint policy and that didn't quite make sense. I've not gotten a full documented list of the API calls that Citrix uses, but we've asked for it.
s
Have you checked CloudTrail? All API calls are logged there
if there's a failure, it'll be listed
but Citrix should be making the call to the Workspaces service
<http://workspaces-instances.amazonaws.com|workspaces-instances.amazonaws.com>
l
We had Citrix and AWS support on while troubleshooting and there were no cloudtrail failures logged. The only error was on the Citrix Cloud side, wiht the message: ErrorDirectUpload: Amazon.EBS.Model.AccessDeniedException: User:XXX is not authorized to perform ec2:createtags on resource: arnawsec2us east 1:snapshot/* because no VPC endpoint policy allows the ec2:createtags action. Our EC2 endpoint policy absolutely does allow create tags. The issue was that the ebs endpoint policy was only allowing ebs:*.* We had to add the ec2*:* to the ebs endpoint policy to let it work.
s
VPC Endpoint policy though is not EC2 policy
interesting
image.png
I think this diagram is a big help
All EC2 mutating calls go through the WorkSpaces Service
l
Can you elaborate on what you mean by "VPC endpoint policy though is not EC2 policy"? In our org, instead of having calls go to the public internet, we have VPC endpoints created for each service, ebs, s3, ec2, etc. So there is an ec2-endpoint, and it's policy is action: ec2:* to allow all EC2 actions on that endpoint. Same for ebs, there's an ebs-endpoint and by default it allows action: ebs:* We had to add ec2:* to the ebs-endpoint policy to get the image creation to work though. We also have a workspaces-instances-endpoint for all things wiht the worksapces-instances service.
s
Ah, that explains your challenge
That's not a normal configuration with our customers.
Given the above diagram @langsbr, can you determine the path for the requests?
l
I dont think I have a good understanding of the differences in mutating vs non mutating api calls
s
Here's what I understand
You make the request in Citrix console
Citrix console makes a workspaces:* API call to Core Managed Instance Service
Core Managed Instance service then must make the EC2:* and EBS:* API calls
but since you are forcing the traffic through a VPC endpoint, there's a additional consideration there and that's where it is failing
is that correct?
So you want to allow the Endpoint policy for the Core Managed Instance service
Keeping in mind, you cannot directly call EC2 and EBS API calls to CMI, only the Core Managed Instance service can
l
Interesting - we are failing on the citrix image creation when we have the ebs-endpoint policy set to only allow ebs actions. We had to allow ec2 actions on the ebs endpoint policy which is what doesn't make sense, unless citrix does an API call that is EBS based, but then does an EC2 action. But if it is supposed to tell the CMI service to do it, I'd expect everything to be going to the CMI-endpoint
I wonder if the difference is that for Citrix, the image prep uses direct EC2 and EBS calls and only VM provisioning is done with workspace instance service calls. The Gold image is just an EC2 instance and we create an AMI and citrix creates a Prep-VM, does the MCS magic, and then has an AMI ready to use.
Open in Slack
PreviousNext
Powered by