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

Don't return secrets in the API & Only update credentials when requested #1022

Merged
merged 9 commits into from
Nov 20, 2020

Conversation

sherifnada
Copy link
Contributor

@sherifnada sherifnada commented Nov 19, 2020

What

  1. Adds JsonSecretsProcessor which exposes methods for expunging or absorbing secrets to and from configuration objects.
  2. Using JsonSecretsProcessor, change Source/Destination endpoints to never return any sensitive configs.
  3. Add a shouldUpdateCredentials flag to SourceUpdate/DestinationUpdate to indicate whether the values of sensitive fields should be updated or not. If not, ignores the value of secrets even if they are set in the input to the update method.

Reading Order

  1. JsonSecretsProcessor.java + JsonSecretsProcessorTest.java
  2. config.yaml
  3. SourceHandler.java
  4. DestinationHandler.java
  5. anything else

TODO

  • fix tests

@sherifnada
Copy link
Contributor Author

Publishing this for review to get feedback since the approach is slightly different than what was laid out in #986 in that we do not introspect into the value of secrets to figure out if they should be updated or not.

@sherifnada sherifnada changed the title Don't return secrets in the API Don't return secrets in the API & Only update credentials when requested Nov 19, 2020
Copy link
Contributor

@cgardens cgardens left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like you went for a different protocol than the one described in the issue, would like to understand the motivations for that change before reviewing more! #986

@@ -1135,6 +1135,8 @@ components:
$ref: "#/components/schemas/SourceId"
connectionConfiguration:
$ref: "#/components/schemas/SourceConfiguration"
updateConfigurationSecrets:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this strategy is different from the originally proposed one in the issue #986. Why the change?

How does this implementation handle the case where a configuration has 2 secrets and only one is updated?

Preconditions.checkArgument(schema.isObject());

ObjectNode properties = (ObjectNode) schema.get(PROPERTIES_FIELD);
JsonNode copy = obj.deepCopy();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Jsons.clone is an option too. I don't know what guarantees deepCopy gives but if you do, then good to go!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

deepCopy can return a different type e.g: ObjectNode. Just a small thing. I didn't realize jsons.clone was a thing

return obj.isObject() && obj.has(AIRBYTE_SECRET_FIELD) && obj.get(AIRBYTE_SECRET_FIELD).asBoolean();
}

private static void assertValidSchema(JsonNode node) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we want to throw is a schema doesn't match our expectations? don't we just want to do nothing? e.g. if there is no top level properties and it is just a oneOf we don't want to fail do we?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fair enough. will fix

@sherifnada
Copy link
Contributor Author

Addressing comments, un-requested review for now

@sherifnada
Copy link
Contributor Author

Ready for another round of review

Copy link
Contributor

@cgardens cgardens left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm! thanks.

@sherifnada sherifnada merged commit 0584067 into master Nov 20, 2020
@sherifnada sherifnada deleted the sherif/obfuscate-secrets branch November 20, 2020 00:03
Copy link
Contributor

@michel-tricot michel-tricot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎉 !!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants