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

Does not support fetching SSM parameters shared via AWS Resource Access Manager #397

Open
thandleman-r7 opened this issue Oct 8, 2024 · 0 comments
Labels
bug Something isn't working

Comments

@thandleman-r7
Copy link

Describe the bug

Hey folks!

We have a secret value we share with all AWS accounts via Resource Access Manager. I would like to leverage Secrets Store CSI Driver and this provider to mount the secret to a workload that relies on the value. However, this is currently not possible with the provider. The documentation states: For SSM Parameter Store, this must be the Name of the parameter and can not be a full ARN.

Because I am hard-headed, I tried anyway just to see what would happen. This results in an error which seems to occur because the name used to fetch the parameter does not match the name returned in the response. Stack trace include below.

This limitation makes it so we cannot use SSM Parameters shared via AWS RAM.

Error On Mount:

panic: runtime error: invalid memory address or nil pointer dereference                                                                                                                            │
│ [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x16aac49]                                                                                                                            │
│                                                                                                                                                                                                    │
│ goroutine 20 [running]:                                                                                                                                                                            │
│ github.com/aws/secrets-store-csi-driver-provider-aws/provider.(*ParameterStoreProvider).fetchParameterStoreBatch(0xc0005916e0?, {0x0, {0xc000700050, 0xe}, {0x20015a0, 0xc000610508}}, {0x1fc2108, │
│     /Users/martysi/Documents/workspaces/upstream_repos/secrets-store-csi-driver-provider-aws/provider/parameter_store_provider.go:157 +0x769                                                       │
│ github.com/aws/secrets-store-csi-driver-provider-aws/provider.(*ParameterStoreProvider).fetchParameterStoreValue(0xc000591620, {0x1fc2108, 0xc000144480}, {0xc0006104f0, 0x1, 0x1}, 0x16acd10?)    │
│     /Users/martysi/Documents/workspaces/upstream_repos/secrets-store-csi-driver-provider-aws/provider/parameter_store_provider.go:85 +0x1b1                                                        │
│ github.com/aws/secrets-store-csi-driver-provider-aws/provider.(*ParameterStoreProvider).GetSecretValues(0x1837d80?, {0x1fc2108, 0xc000144480}, {0xc0006104f0, 0x1, 0x1}, 0xc00059a900?)            │
│     /Users/martysi/Documents/workspaces/upstream_repos/secrets-store-csi-driver-provider-aws/provider/parameter_store_provider.go:63 +0x172                                                        │
│ github.com/aws/secrets-store-csi-driver-provider-aws/server.(*CSIDriverProviderServer).Mount(0xc0006250b0, {0x1fc2108, 0xc000144480}, 0xc000092100)                                                │
│     /Users/martysi/Documents/workspaces/upstream_repos/secrets-store-csi-driver-provider-aws/server/server.go:149 +0xb62                                                                           │
│ sigs.k8s.io/secrets-store-csi-driver/provider/v1alpha1._CSIDriverProvider_Mount_Handler({0x1a49960?, 0xc0006250b0}, {0x1fc2108, 0xc000144480}, 0xc000092080, 0x0)                                  │
│     /Users/martysi/go/pkg/mod/sigs.k8s.io/secrets-store-csi-driver@v1.4.0/provider/v1alpha1/service_grpc.pb.go:132 +0x169                                                                          │
│ google.golang.org/grpc.(*Server).processUnaryRPC(0xc0001c5e00, {0x1fc2108, 0xc0001443f0}, {0x1fc72d8, 0xc000007520}, 0xc000556000, 0xc000625140, 0x2d33518, 0x0)                                   │
│     /Users/martysi/go/pkg/mod/google.golang.org/grpc@v1.60.1/server.go:1372 +0xe03                                                                                                                 │
│ google.golang.org/grpc.(*Server).handleStream(0xc0001c5e00, {0x1fc72d8, 0xc000007520}, 0xc000556000)                                                                                               │
│     /Users/martysi/go/pkg/mod/google.golang.org/grpc@v1.60.1/server.go:1783 +0xfec                                                                                                                 │
│ google.golang.org/grpc.(*Server).serveStreams.func2.1()                                                                                                                                            │
│     /Users/martysi/go/pkg/mod/google.golang.org/grpc@v1.60.1/server.go:1016 +0x59                                                                                                                  │
│ created by google.golang.org/grpc.(*Server).serveStreams.func2 in goroutine 37                                                                                                                     │
│     /Users/martysi/go/pkg/mod/google.golang.org/grpc@v1.60.1/server.go:1027 +0x115

To Reproduce

Steps to reproduce the behavior:

  1. Share an SSM Parameter via AWS Resource Access Manager to another account with an EKS Cluster with ASCP installed.
  2. Create a SecretProviderClass with the ARN of the shared resourced as the objectName of one of the objects.
  3. Mount the SPC to a pod.

Do you also notice this bug when using a different secrets store provider (Vault/Azure/GCP...)? No

Expected behavior
ASCP should be able to handle AWS RAM-shared SSM parameters.

Environment:
EKS 1.29

Additional context

RAM-shared SSM paremeter: arn:aws:us-east-1:123456789012:ssm:parameter/foo/bar

SecretProviderClass:

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metdata:
  name: foobar
  namespace: baz
spec:
  provider: aws
  parameters:
    objects: |
      - objectName: arn:aws:us-east-1:123456789012:ssm:parameter/foo/bar 
        objectType: ssmparameter

GetParametersResponse:

{
    "Parameters": [
        {
            "Name": "/foo/bar",
            "Type": "String",
            "ARN": "arn:aws:ssm:us-east-1:123456789012:parameter/foo/bar",
            "DataType": "text",
            ...
        }
    ],
    "InvalidParameters": []
}

Looking at the lines where error gets thrown, you can see it uses Name from the response. When trying to supply this to the batchDesc map, it results in a nil descriptor since the key should be the ARN of the parameter.

rsp, err := client.Client.GetParametersWithContext(ctx, &ssm.GetParametersInput{
Names: names,
WithDecryption: aws.Bool(true),
})
if err != nil {
return nil, fmt.Errorf("%s: Failed fetching parameters: %w", client.Region, err)
}
if len(rsp.InvalidParameters) != 0 {
err = awserr.NewRequestFailure(awserr.New("", fmt.Sprintf("%s: Invalid parameters: %s", client.Region, strings.Join(aws.StringValueSlice(rsp.InvalidParameters), ", ")), err), 400, "")
return nil, err
}
// Build up the results from the batch
for _, parm := range rsp.Parameters {
descriptor := batchDesc[*(parm.Name)]
secretValue := &SecretValue{
Value: []byte(*(parm.Value)),
Descriptor: *descriptor,
}

It seems that this issue could be solved by checking if descriptor is nil after 153, and if so, trying to use the ARN instead as the key.

@thandleman-r7 thandleman-r7 added the bug Something isn't working label Oct 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant