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
🎉 New implementation for AWS Secret Manager for issue #19690
🎉 New implementation for AWS Secret Manager for issue #19690
Conversation
Hello 👋, first thank you for this amazing contribution. We really appreciate the effort you've made to improve the project. If you have any questions feel free to send me a message in Slack! |
Hi @marcosmarxm, thanks for your reply; I understand Thanksgiving is a slow week for all of us. I'm looking forward to any feedback you guys have on this. In the meantime, I've been merging from Happy Thanksgiving Mauricio |
Thanks for the contribution @mauricioalarcon ! @pmossman will take a look over the next few days! |
Thank you @davinchia - I'm looking forward to hear from @pmossman |
Hey @mauricioalarcon , thanks for the contribution! This is on my todo-list for this week. At first glance, it looks good to me, but I'll want to spend some time trying it out before I approve it. I'll keep you updated! |
Actually @mauricioalarcon it looks like our Snyk security scan found a vulnerability introduced by that aws-secretsmanager package that your PR introduces: Perhaps there's a newer version of the package with that vulnerability fixed? Or perhaps there's a way to force one of the fixed versions of jackson-databind as indicated in the screenshot? |
Interesting, yes, I see there's an updated version. I've just bumped it; I also added some new argument checks. I think this should be fixed by now, I see it now brings |
Hmm that's odd, Snyk is now reporting a different security issue, this time for I might need to pull in some extra eyes on this one for debugging gradle dependencies, I'll try to check back in tomorrow, sorry for the trouble @mauricioalarcon ! |
@mauricioalarcon I've determined that Snyk's complaint about the dependency is a false alarm, since we declare an updated version of jackson-databind globally, but Snyk isn't able to detect it. I've manually marked your PR as resolved in Snyk so we shouldn't see that check fail any more. I'm currently looking into how our CI system will run the integration test for the AWS secret manager. We have some specialized setup for testing our GCP secret manager in our CI, so I'm going to see what we need to do to make the AWS secret manager work in a similar fashion. It might be non-trivial, since I think we have a dedicated GCP project stood up for integration tests, and we might need to create something similar for AWS. I'll keep working to move this forward, just wanted to give you a quick end-of-week update. Have a good weekend! |
daa5324
to
e3ac0ad
Compare
Thanks @pmossman, for the update and work on this. The only thing needed for the integration test will be just an account where we can run these. lmk if I can help in any way, shape or form. |
* @see SecretCache | ||
*/ | ||
public AWSSecretManagerPersistence() { | ||
this.client = AWSSecretsManagerClientBuilder.defaultClient(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mauricioalarcon before we get this PR merged, can you incorporate the AWS Secret Manager into https://github.com/airbytehq/airbyte/blob/92f71accea6674f04cabf1bcdc8a48f7f4866905/airbyte-config/config-persistence/src/main/java/io/airbyte/config/persistence/split_secrets/SecretPersistence.java similar to GOOGLE_SECRET_MANAGER
and VAULT
?
We have two "modes" for secret persistence layers, "ephemeral" and "long-lived". For Google Secret Manager, we define separate TTLs for each, but for Vault, both use the same underlying implementation. I think for now, we can use the same implementation of the AWS Secret Manager for both, unless you want to take a look at the Google internals and replicate something similar for AWS, by all means go for it!
One final important note: these other secret persistence classes use credentials and configurations from our Configs.java
, and I think it'd make sense to add some new configs for AWS Secrets Manager so that we're not relying on any defaults.
For example, these configs power the Vault-based secret persistence: https://github.com/airbytehq/airbyte/blob/master/airbyte-config/config-models/src/main/java/io/airbyte/config/Configs.java#L134-L150
And the implementation for these methods are here: https://github.com/airbytehq/airbyte/blob/master/airbyte-config/config-models/src/main/java/io/airbyte/config/EnvConfigs.java#L396-L409
This will make it easier for various environments to configure the AWS Secret manager, without needing to rely on default profiles, which can get particularly cumbersome in some environments where multiple profiles exist.
Let me know if you have any questions around any of that! Really appreciate your contribution here :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @pmossman all of these changes make sense. I'll work on these and send an update to the PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pmossman I adjusted the PR with the requested changes; I added the new config keys as part of the instructions at docs/operator-guides/configuring-airbyte.md
, I'm not sure where else I need to update, if any.
As for the "ephemeral", that's not an option for AWS; that will require a bit more logic to mimic the TTL. I'll research a bit more on this, I'll keep you updated.
Thank you
@pmossman - I think I know why the deployments were failing; due to formatting ? sorry, - I've just ran formatter and updated the PR. |
07dda51
to
56f990c
Compare
@mauricioalarcon I think this is very close, I'm just looking into a failing acceptance test that I believe is unrelated to your change. I think the s3 dependency version bump that I included in this PR is causing an S3-related connector to fail in our test suite, so I'm going to revert it in a separate branch and see what happens to our tests. Your changes in this PR look great so once I figure out this final dependency issue we should be good to merge |
@pmossman Thanks for the update - let me know if I can help. |
airbytehq#10518 Added new implementation AWSSecretManagerPersistence and integration tests AWSSecretManagerPersistenceIntegrationTest A new implementation of SecretPersistence to support AWS Secret Manager AWSSecretManagerPersistence New Integration tests as suggested on the open Issue, similar to GCP secret manager
- Added new argument check for AWS Secret Manager.
…ind from being pulled in
- Externalized configurations for AWS Secret Manager into Configs and EnvConfigs.java as requested. - Adjusted test to use new constructor for `AWSSecretManagerPersistence` - Augmented instructions configuring-airbyte.md with the new config keys.
78f4bf1
to
a24ca65
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mauricioalarcon I verified that your PR passes our full suite of acceptance tests on another branch of mine, and I verified that the security warning from Snyk can be disregarded as it isn't smart enough to see that we're pulling in a fixed version of transitive dependencies.
Thanks so much for your contribution and for making the AWS Secret Manager compatible with our EnvConfigs setup! Sorry this took so much back and forth, we're still working on making our tooling around community PRs more streamlined, and your particular PR gave us some great data points for improving the process.
Thanks again!
@pmossman That's amazing - thanks a lot; I'm happy to help with such a fantastic product that's Airbyte. |
case AWS_SECRET_MANAGER -> { | ||
return Optional.of(new AWSSecretManagerPersistence(configs.getAwsAccessKey(), configs.getAwsSecretAccessKey())); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
any reason to not support IAM role based authentication ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Airbyte project at large doesn't seem to support role based auth at all, which is pretty rough.
Are there any docs on how to fetch secrets from |
What
Initial implementation for AWS Secret Manager for issue
#10518
Added new implementation
AWSSecretManagerPersistence
and integration testsAWSSecretManagerPersistenceIntegrationTest
How
A new implementation of
SecretPersistence
to support AWS Secret ManagerAWSSecretManagerPersistence
New Integration tests as suggested on the open Issue, similar to GCP secret manager
🚨 User Impact 🚨
No breaking changes, you need a new set of AWS credentials and AWS cli installed in order to run integration test.
Also note that the credentials need the following
Pre-merge Checklist
Expand the relevant checklist and delete the others.
New Feature Implemenation
Community member or Airbyter
./gradlew :airbyte-integrations:connectors:<name>:integrationTest
.Tests
Unit
*Building Airbyte Sub Build: PLATFORM
Type-safe dependency accessors is an incubating feature.
Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0.
You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.
See https://docs.gradle.org/7.4/userguide/command_line_interface.html#sec:command_line_warnings
BUILD SUCCESSFUL in 1s
13 actionable tasks: 13 up-to-date
*
Integration
Gist with results here
Acceptance
Gist with results here