5 ms·

Hi, this really needs a REST API. Most secrets are injected in real time at the startup of of a container. For tools like this or plugins in k8 / docker to acc

by auspex 9y ago

Hi, this really needs a REST API. Most secrets are injected in real time at the startup of of a container. For tools like this or plugins in k8 / docker to access your store you should support this. It's really bad practice to create a hard dependency on your secrets store by using the Java sdk directly in your application. If that's not the intent definitely provide a Golang sdk for proper plugin integration. Can you explain how secrets are injected now?

stiankri 9y ago
Today people are using the SDK directly or injecting secrets via the CLI. Multi-language support and integration with e.g. Kubernetes is high on the wish list. The approach we are looking at for multi-language support is to drop the dependency on the AWS Encryption SDK. Creating a read-only SDK in other languages is then straight forward.
- rad_gruchalski 9y ago
  Sure, but what if the language I'm using is not high on your priority list? Isn't it easier to add a high level rest api?
  - stiankri 9y ago
    That is certainly one approach we have looked at. The question then is where would you run the REST API? As a side car, as a separate service, e.g. using AWS API Gateway and Lambdas? If you look at the work required to write a simplified read-only client using the AWS SDK for KMS and DynamoDB, while perhaps a bit more work than integrating with a REST API, it is not that far off, which is why we are considering that approach. That would of course not help if you are using a language that does not have an AWS SDK.
    - auspex 9y ago
      Any of the suggestions above would most likely work. Running an API sidecar or separate service would just be the cost of exposing the REST API. I could definitely envision people deciding against using your key store when comparing to something like Vault based just on the fact that you limit extensibility with no API.
    - rad_gruchalski 9y ago
      All AWS SDKs use the underlying REST(ey) API. The SDKs are literally machine generated. I can download the WSDLs or take these files https://github.com/aws/aws-sdk-go/tree/master/models/apis https://github.com/aws/aws-sdk-go/tree/master/models/apis and generate one myself.

by auspex 9y ago

stiankri 9y ago

Today people are using the SDK directly or injecting secrets via the CLI. Multi-language support and integration with e.g. Kubernetes is high on the wish list. The approach we are looking at for multi-language support is to drop the dependency on the AWS Encryption SDK. Creating a read-only SDK in other languages is then straight forward.

rad_gruchalski 9y ago
Sure, but what if the language I'm using is not high on your priority list? Isn't it easier to add a high level rest api?
- stiankri 9y ago
  That is certainly one approach we have looked at. The question then is where would you run the REST API? As a side car, as a separate service, e.g. using AWS API Gateway and Lambdas? If you look at the work required to write a simplified read-only client using the AWS SDK for KMS and DynamoDB, while perhaps a bit more work than integrating with a REST API, it is not that far off, which is why we are considering that approach. That would of course not help if you are using a language that does not have an AWS SDK.
  - auspex 9y ago
    Any of the suggestions above would most likely work. Running an API sidecar or separate service would just be the cost of exposing the REST API. I could definitely envision people deciding against using your key store when comparing to something like Vault based just on the fact that you limit extensibility with no API.
  - rad_gruchalski 9y ago
    All AWS SDKs use the underlying REST(ey) API. The SDKs are literally machine generated. I can download the WSDLs or take these files https://github.com/aws/aws-sdk-go/tree/master/models/apis https://github.com/aws/aws-sdk-go/tree/master/models/apis and generate one myself.