-
Notifications
You must be signed in to change notification settings - Fork 1.7k
AMBARI-24742. Encrypting/decrypting PASSWORD type properties when inserting them into the DB/using them #2458
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
Conversation
|
Refer to this link for build results (access rights to CI server needed): |
|
retest this please |
|
Refer to this link for build results (access rights to CI server needed): |
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.
Can you document what the additional keys are for this implementation?
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.
will do
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.
I think we tend to use CollectionUtils.isNotEmpty(passwordProperties) instead of the long form 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.
nice catch; I'll change it
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.
How will a stack upgrade affect this?
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.
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?
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.
During a stack upgrade, new properties are added and possibly properties change types. How will this cache behave?
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.
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)
b70f463 to
16c8446
Compare
|
Refer to this link for build results (access rights to CI server needed): |
|
retest this please |
|
Refer to this link for build results (access rights to CI server needed): |
1541a16 to
633d988
Compare
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
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 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.
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.
But the caller should not be down casted to the implementation.
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.
I think it may be replaced with java.util.concurrent.ConcurrentHashMap#computeIfAbsent . As a bonus, we would get atomic check/assigment
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 for this hint (I've to admit I did not know about this option)
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.
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
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.
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.
|
Tested the following use cases (sensitive data encryption is turned on):
Everything went fine. |
|
Refer to this link for build results (access rights to CI server needed): |
19edde1 to
fe0b822
Compare
|
Refer to this link for build results (access rights to CI server needed): |
fe0b822 to
d3d49ae
Compare
|
I had to rebase locally and send a new patch to be able to merge with trunk |
|
Refer to this link for build results (access rights to CI server needed): |
|
retest this please |
|
Refer to this link for build results (access rights to CI server needed): |
33465d7 to
466013c
Compare
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
…erting them into the DB/using them
…ed additional information we need for encryption and using 3rd party to check if password property set of a config type is netiher null nor empty
bc2d699 to
587d796
Compare
|
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<>()) |
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.
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.
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.
hm..that's true. I may remove that layer next week.
|
Refer to this link for build results (access rights to CI server needed): |
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:
ambari-server setup-securityCLI (using option Fixed missing } in configuration.md #2 - Encrypt passwords stored in ambari.properties file)server.security.encrypt_sensitive_datais set totrueHow was this patch tested?
In addition to unit testing I executed several E2E tests:
After creating a new
ssl-serverconfiguration:Checking my changes using Ambari API (modified the code a little bit temporarily to avoid secret reference replacement):
