Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DeployLocally - Failed to assume role #1144

Closed
sandeephs1 opened this issue Apr 4, 2024 · 3 comments
Closed

DeployLocally - Failed to assume role #1144

sandeephs1 opened this issue Apr 4, 2024 · 3 comments
Assignees
Labels
type: documentation Improvements or additions to documentation type: question Further information is requested
Milestone

Comments

@sandeephs1
Copy link

Hello team, we use deploy locally (docker) for Development related unit testing to keep the Dev cycle shorter.
But constantly we face this issue (Failed to assume role) when ever start creating Dataset and hence cannot move forward with other features
P.S. Environment was bootstrapped successfully.

Any suggestion, having locally running set up help each Dev member to speed up the Dev cycle.

it is data.all 2.0.0
Error -

Failed to assume role arn:aws:iam::0123456789:role/dataallPivotRole due to: An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:sts::0123456789::assumed-role/AWSReservedSSO_AdministratorAccess_45dcebf19bca3ec8/sandeep@email.com is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::0123456789:role/dataallPivotRole

@dlpzx
Copy link
Contributor

dlpzx commented Apr 9, 2024

Hi @sandeephs1 this issue is most probably due to the permissions of your user and the restrictions of the pivotRole.

Both, dataallPivotRole and dataallPivotRole-cdk have a trust policy that limits the principals that can assume the role. In the CloudFormation definition we restrict it to the following roles:

                  !Sub "arn:aws:iam::${AwsAccountId}:role/*graphql-role",
                  !Sub "arn:aws:iam::${AwsAccountId}:role/*awsworker-role",
                  !Sub "arn:aws:iam::${AwsAccountId}:role/*ecs-tasks-role"

arn:aws:sts::0123456789::assumed-role/AWSReservedSSO_AdministratorAccess_45dcebf19bca3ec8/sandeep@email.com does not fulfill any of the conditions. For local development you can remove that permission so that your role can assume the pivot role.

Thanks for drawing our attention to the issue, we will update the docs

@dlpzx dlpzx added the type: question Further information is requested label Apr 9, 2024
@dlpzx dlpzx added the type: documentation Improvements or additions to documentation label Apr 12, 2024
@anmolsgandhi anmolsgandhi added this to the v2.4.0 milestone Apr 15, 2024
@dlpzx
Copy link
Contributor

dlpzx commented Apr 15, 2024

At first we thought about including more documentation, but after speaking with @petrkalos I think we should think of a more streamlined experience for developers. Starting data.all locally should be the easiest of tasks for a developer. As part of these efforts we want to:

  • avoid SSM parameters in the local development
  • avoid trust policies in pivot roles for local development
    Maybe we can do that through a local configuration file or with docker. What do you think @sandeephs1, @noah-paige, @SofiaSazonova?

@dlpzx dlpzx self-assigned this Apr 15, 2024
dlpzx added a commit that referenced this issue Apr 16, 2024
…oles (#1176)

### Feature or Bugfix
- Feature

### Detail
When the environment is local (local deployment using docker), the pivot
role that is created has a more open trust policy. Instead of
restricting with externalId and naming conventions, the local pivot role
can be assumed by the credentials account.

### Relates
- #1144 

### Security
Please answer the questions below briefly where applicable, or write
`N/A`. Based on
[OWASP 10](https://owasp.org/Top10/en/).

- Does this PR introduce or modify any input fields or queries - this
includes
fetching data from storage outside the application (e.g. a database, an
S3 bucket)? `N/A`.
  - Is the input sanitized?
- What precautions are you taking before deserializing the data you
consume?
  - Is injection prevented by parametrizing queries?
  - Have you ensured no `eval` or similar functions are used?
- Does this PR introduce any functionality or component that requires
authorization? `N/A`.
- How have you ensured it respects the existing AuthN/AuthZ mechanisms?
  - Are you logging failed auth attempts?
- Are you using or adding any cryptographic features? `N/A`.
  - Do you use a standard proven implementations?
  - Are the used keys controlled by the customer? Where are they stored?
- Are you introducing any new policies/roles/users? ---> ⚠️ Yes, in this
PR the trust policy for the pivot role created by CDK in the data.all
local environment changes. The trust policy for AWS deployments stays
the same
- Have you used the least-privilege principle? How? ---> the change only
affects local deployment where the trust policy requirements can be more
relaxed because it is going to be used by developers to develop locally


By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 license.
@dlpzx
Copy link
Contributor

dlpzx commented Apr 16, 2024

@sandeephs1 #1176 should resolve this issue, but we will work on other improvements to simplify the developer experience. If you have any suggestions or pain points please comment in this issue: #1180

@dlpzx dlpzx closed this as completed Apr 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: documentation Improvements or additions to documentation type: question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants