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

Handle access denied exceptions on resources #666

Closed
eliecharra opened this issue Jun 21, 2021 · 3 comments
Closed

Handle access denied exceptions on resources #666

eliecharra opened this issue Jun 21, 2021 · 3 comments
Assignees
Labels
kind/bug Something isn't working priority/1
Milestone

Comments

@eliecharra
Copy link
Contributor

eliecharra commented Jun 21, 2021

Description
We want to handle access denied exceptions when reading resources details.

Environment

  • OS: any
  • driftctl version: any
  • terraform version: not related
  • terraform providers versions: not related

How to reproduce
#665 (comment)

Possible Solution
We need to do string matching on error strings coming from ReadResource
We can reproduce an error behavior by enabling listing but deny every detail fetcher call (remove lambda:GetFunction from policy)
We can retrieve the error string with : err.Error()
Error should be handled in scanner.go when we iterate on details fetcher, like we did above for enumeration errors

resourceWithDetails, err := fetcher.ReadDetails(res)
				if err != nil {
                                       // HERE
					return nil, err
				}

We should test behavior for every kind of resource since AWS does not return the same error code.
If we match an access denied exception, we should send an alert and skip the resource.

@eliecharra eliecharra added the kind/bug Something isn't working label Jun 21, 2021
@eliecharra eliecharra added this to Triage in driftctl via automation Jun 21, 2021
@eliecharra eliecharra moved this from Triage to Todo in driftctl Jun 21, 2021
@sjourdan sjourdan modified the milestones: v0.11.0, v0.12.0 Jun 22, 2021
@sjourdan sjourdan moved this from Ready To Develop to Under Investigation in driftctl Jun 24, 2021
@sundowndev sundowndev assigned sundowndev and unassigned sundowndev Jun 25, 2021
@eliecharra
Copy link
Contributor Author

eliecharra commented Jun 25, 2021

Blocked by deep mode refactoring

@eliecharra eliecharra moved this from Under Investigation to Backlog in driftctl Jun 25, 2021
@sjourdan sjourdan modified the milestones: v0.12.0, v0.1x.0, v0.13.0 Jul 8, 2021
@eliecharra eliecharra moved this from Backlog to Under Investigation in driftctl Jul 16, 2021
@sjourdan sjourdan removed this from the v0.1x.0 milestone Jul 16, 2021
@eliecharra eliecharra moved this from Under Investigation to Ready To Develop in driftctl Jul 23, 2021
@sundowndev sundowndev self-assigned this Jul 23, 2021
@moadibfr moadibfr moved this from Ready To Develop to In Progress in driftctl Jul 23, 2021
@sjourdan
Copy link
Contributor

I have a similar use case. One of my top-secret S3 buckets has a strict access policy that will prevent driftctl to scan it (and return a very expected 403).

Here's the policy:

{
    "Version": "2012-10-17",
    "Id": "S3PolicyId1",
    "Statement": [
        {
            "Sid": "IPAllow",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::yaddabucket0130",
                "arn:aws:s3:::yaddabucket0130/*"
            ],
            "Condition": {
                "NotIpAddress": {
                    "aws:SourceIp": "1.2.3.4/32"
                }
            }
        }
    ]

@eliecharra eliecharra added this to the v0.14 milestone Jul 27, 2021
@eliecharra eliecharra assigned sjourdan and unassigned sundowndev Aug 2, 2021
@eliecharra eliecharra moved this from In Progress to Review in driftctl Aug 2, 2021
@eliecharra eliecharra moved this from Review to In Progress in driftctl Aug 3, 2021
@eliecharra eliecharra assigned sundowndev and unassigned sjourdan Aug 3, 2021
@sundowndev sundowndev assigned sjourdan and unassigned sundowndev Aug 4, 2021
@sundowndev sundowndev moved this from In Progress to Review in driftctl Aug 4, 2021
@sjourdan
Copy link
Contributor

sjourdan commented Aug 4, 2021

LGTM

Context: 1 S3 bucket in the account has an explicit ban for my IP ("yaddabucket0130").

Using 0.13

❯  LOG_LEVEL=error driftctl scan 
Scanned states (1) 
AccessDenied: Access Denied
        status code: 403, request id: PC50JPFPQJSP0735, host id: /GGji2ootu3WqRQNX7hEQxdAmXJSP5B1uYo3Dpo8unwmCXjLQJUF1fLsnTACjg70PMuN+VK8LvU=

Using 0.14-pre

❯  LOG_LEVEL=error driftctl-pre scan 
Scanned states (1) 
Found resources not covered by IaC:
  aws_s3_bucket:
    - a-bucket-filled-with-files
    - [...]
    - 
Ignoring aws_s3_bucket.yaddabucket0130 from drift calculation: Listing aws_s3_bucket is forbidden.

It seems that we got access denied exceptions while listing resources.
The latest minimal read-only IAM policy for driftctl is always available here, please update yours: https://docs.driftctl.com/aws/policy

@sjourdan sjourdan closed this as completed Aug 4, 2021
driftctl automation moved this from Review to Done Aug 4, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Something isn't working priority/1
Projects
None yet
Development

No branches or pull requests

3 participants