IT-3988: Add role to invoke model and move inline sso policy to managed policy #1277
Conversation
| @@ -641,18 +641,6 @@ SsoLlmDeveloper: | |||
| managedPolicies: | |||
| - 'arn:aws:iam::aws:policy/AmazonBedrockFullAccess' | |||
| - 'arn:aws:iam::aws:policy/AWSCloudFormationFullAccess' | |||
| # https://stackoverflow.com/questions/58125181/cloud-formation-cant-upload-template-file | |||
There was a problem hiding this comment.
Moving to a managed policy with the hope we can tweak it manually until we get what we need. Inline, we get an error because it's under AWS control.
org-formation/600-access/_tasks.yaml
Outdated
| @@ -388,3 +388,31 @@ SynapseAthenaUserAccessPolicy: | |||
| ] | |||
| } | |||
| PolicyName: SynapseAthenaUserAccessPolicy | |||
|
|
|||
| SynapseLlmBedrockAgentPolicy: | |||
There was a problem hiding this comment.
@zaro0508 , wondering if I should have the policy here or if I should move it as a resource alongside the bedrock agent role below.
There was a problem hiding this comment.
@zaro0508 , wondering if I should have the policy here or if I should move it as a resource alongside the bedrock agent role below.
You'll notice that existing policy definitions created in here are meant to be applied to all accounts (Account: '*') because some AWS features require us to apply the same policy. If you are intending to apply this to one account then I would say that it's more appropriate to setup this policy with the resource that needs it.
xschildw
changed the title
There was a problem hiding this comment.
From reading the issue it looks like the goal is to update the sso llm developer role with a few missing permissions however I don't understand your implementation to accomplish that goal. I might be missing something but I don't see an explanation as to why you need to make all these changes to accomplish your goal. Why not just keep the format as-is and update the inline policy in org-formation/700-aws-sso/_tasks.yaml?
|
We first have to determine which permissions we need, ideally out of the PR cycle (i.e. only have one PR with everything we need). With an inline policy, we are not able to add permissions manually in the console (the policy in under AWS control). So we're trying to setup a managed policy, and in next PR we'll reference it in the role. |
ahh, i didn't realize that there is no way to update an inline policy in AWS console. For testing purposes, I typically use the AWS console to manually create a new inline policy with additional access and apply that to a role. That lets me craft a least privilege policy before committing it to cloudformation. Anyways, now that I understand I don't have a problem with your approach either it just makes it more difficult to follow in this org-formation/cloudformation setup. |
org-formation/600-access/_tasks.yaml
Outdated
| } | ||
| PolicyName: SynapseLlmDeveloperPolicy | ||
|
|
||
| BedrockAgentRole: |
There was a problem hiding this comment.
why is this role necessary when the goal is to only fix the developer role?
There was a problem hiding this comment.
This is the policy for the user (sso-llmdeveloper) to be able to work in the console/cloudformation to create an agent.
| @@ -0,0 +1,35 @@ | |||
| AWSTemplateFormatVersion: '2010-09-09' | |||
There was a problem hiding this comment.
This is the role used by the agent when it's running. It has the right to execute a model.
| Description: The ARN of the Bedrock Agent Role | ||
| Value: !GetAtt bedrockAgentRole.Arn | ||
| Export: | ||
| Name: BedrockAgentRoleArn |
There was a problem hiding this comment.
outputs need to be unique therefore it would be better if you add stack name here, i.e. !Sub '${AWS::StackName}-BedrockAgentRoleArn'
This PR fixes a deployment issue in #1277 caused by a missing '!Ref'.
This PR creates a role that gives Bedrock permission to execute model