Skip to content

Conversation

@smolnar82
Copy link
Contributor

What changes were proposed in this pull request?

Sensitive service configuration values should be encrypted in the Ambari server DB, if enabled.

Sensitive service configuration values are defined by a service's configuration metadata. Properties are defined in XML files under the service's definition directory and contain attributes that Ambari may use to determine whether they should be encrypted or not.

Currently, Ambari uses the property-type attribute to determine the type of property. If the value of this attribute is PASSWORD, than the value is considered sensitive and should be encrypted.

The Ambari server should encrypt sensitive configuration values if the following has been met:

  1. A master key has been setup using the ambari-server setup-security CLI (using option Fixed missing } in configuration.md #2 - Encrypt passwords stored in ambari.properties file)
  2. The Ambari server configuration property named server.security.encrypt_sensitive_data is set to true

How was this patch tested?

In addition to unit testing I executed several E2E tests:
After creating a new ssl-server configuration:

screen shot 2018-10-14 at 1 35 13 am

Checking my changes using Ambari API (modified the code a little bit temporarily to avoid secret reference replacement):
screen shot 2018-10-14 at 1 34 53 am

@asfgit
Copy link

asfgit commented Oct 15, 2018

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/4271/
Test FAILed.
Test FAILured.

@smolnar82
Copy link
Contributor Author

retest this please

@asfgit
Copy link

asfgit commented Oct 15, 2018

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/4273/
Test PASSed.

Copy link
Contributor

Choose a reason for hiding this comment

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

Can you document what the additional keys are for this implementation?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

will do

Copy link
Contributor

Choose a reason for hiding this comment

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

I think we tend to use CollectionUtils.isNotEmpty(passwordProperties) instead of the long form here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

nice catch; I'll change it

Copy link
Contributor

Choose a reason for hiding this comment

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

How will a stack upgrade affect this?

Copy link
Contributor Author

@smolnar82 smolnar82 Oct 15, 2018

Choose a reason for hiding this comment

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

nice catch; I'll handle that situation like this: subscribing to org.apache.ambari.server.events.StackUpgradeFinishEvent and clean the map when this happened.

Any objection?

Copy link
Contributor

Choose a reason for hiding this comment

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

During a stack upgrade, new properties are added and possibly properties change types. How will this cache behave?

Copy link
Contributor Author

@smolnar82 smolnar82 Oct 16, 2018

Choose a reason for hiding this comment

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

Upon stack upgrade finish the cache will be purged. So that proceeding encryption actions will re-build it.
See the latest patch I submitted (grep for onStackUpgradeFinished)

@smolnar82 smolnar82 force-pushed the AMBARI-24742_part_2 branch from b70f463 to 16c8446 Compare October 15, 2018 20:40
@asfgit
Copy link

asfgit commented Oct 15, 2018

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/4277/
Test FAILed.
Test FAILured.

@smolnar82
Copy link
Contributor Author

retest this please

@asfgit
Copy link

asfgit commented Oct 16, 2018

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/4278/
Test FAILed.
Test FAILured.

@smolnar82 smolnar82 force-pushed the AMBARI-24742_part_2 branch 2 times, most recently from 1541a16 to 633d988 Compare October 16, 2018 09:17
@asfgit
Copy link

asfgit commented Oct 16, 2018

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/4279/
Test FAILed.
Test FAILured.

@asfgit
Copy link

asfgit commented Oct 16, 2018

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/4280/
Test PASSed.

Copy link
Contributor

Choose a reason for hiding this comment

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

Any reason why we pass these arguments as a Object[] ? I see it comes from the interface, but the caller still needs to know which is the underlying implementation in use to fill these params correctly.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

But the caller should not be down casted to the implementation.

Copy link

Choose a reason for hiding this comment

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

I think it may be replaced with java.util.concurrent.ConcurrentHashMap#computeIfAbsent . As a bonus, we would get atomic check/assigment

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for this hint (I've to admit I did not know about this option)

Copy link

Choose a reason for hiding this comment

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

Are not we replacing here an instance of ConcurrentHashMap with an instance of a plain HashMap (that is unsafe for concurrent use)? I think we access and modify cluster properties from different threads

Copy link
Contributor Author

@smolnar82 smolnar82 Oct 16, 2018

Choose a reason for hiding this comment

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

Those properties are generated by ConfigFactory after they have been parsed out from the request: https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ConfigurationResourceProvider.java#L139
As you can see this is a simple HashMap. Which is ok since we guard the actual Config creation with locks and can not be happening that we have multiple properties map for the same version.

Moreover, those properties are being queried in ConfigImpl.getProperties(), which did simply wrapped the internal properties map in a HashMap in previous versions and does it here too.

@smolnar82
Copy link
Contributor Author

Tested the following use cases (sensitive data encryption is turned on):

  • updated config before upgrade
  • did a stack upgrade (added a new PASSWORD type property to cover that case too)
  • updated config after upgrade

Everything went fine.

@asfgit
Copy link

asfgit commented Oct 18, 2018

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/4329/
Test PASSed.

@smolnar82 smolnar82 force-pushed the AMBARI-24742_part_2 branch from 19edde1 to fe0b822 Compare October 19, 2018 07:15
@asfgit
Copy link

asfgit commented Oct 19, 2018

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/4335/
Test PASSed.

@smolnar82 smolnar82 force-pushed the AMBARI-24742_part_2 branch from fe0b822 to d3d49ae Compare October 19, 2018 08:14
@smolnar82
Copy link
Contributor Author

I had to rebase locally and send a new patch to be able to merge with trunk

@asfgit
Copy link

asfgit commented Oct 19, 2018

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/4336/
Test FAILed.
Test FAILured.

@smolnar82
Copy link
Contributor Author

retest this please

@asfgit
Copy link

asfgit commented Oct 19, 2018

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/4338/
Test PASSed.

@smolnar82 smolnar82 force-pushed the AMBARI-24742_part_2 branch 2 times, most recently from 33465d7 to 466013c Compare October 19, 2018 11:37
@asfgit
Copy link

asfgit commented Oct 19, 2018

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/4340/
Test FAILed.
Test FAILured.

@asfgit
Copy link

asfgit commented Oct 19, 2018

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/4341/
Test FAILed.
Test FAILured.

@asfgit
Copy link

asfgit commented Oct 19, 2018

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/4342/
Test FAILed.
Test FAILured.

@asfgit
Copy link

asfgit commented Oct 19, 2018

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/4343/
Test FAILed.
Test FAILured.

@smolnar82 smolnar82 force-pushed the AMBARI-24742_part_2 branch from bc2d699 to 587d796 Compare October 19, 2018 13:19
@smolnar82
Copy link
Contributor Author

Rebased locally with a new change to avoid Swagger issue (unrelated to my changes)


private Set<String> getPasswordProperties(Cluster cluster, StackId stackId, String configType) {
final long clusterId = cluster.getClusterId();
clusterPasswordProperties.computeIfAbsent(clusterId, v -> new ConcurrentHashMap<>()).computeIfAbsent(stackId, v -> new ConcurrentHashMap<>())
Copy link
Contributor

Choose a reason for hiding this comment

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

Why bother caching using the cluster id at all. Even if Ambari was managing multiple clusters, the stack definitions all would be the same for the same stack id.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

hm..that's true. I may remove that layer next week.

@asfgit
Copy link

asfgit commented Oct 19, 2018

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/4345/
Test PASSed.

@smolnar82 smolnar82 merged commit 9c61584 into apache:trunk Oct 19, 2018
@smolnar82 smolnar82 deleted the AMBARI-24742_part_2 branch October 19, 2018 15:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants