AMBARI-24776. Allow the agent's SSL certificate data to be accessible by heartbeat handlers (amagyar)

[zeroflag]

What changes were proposed in this pull request?

The agents certificate should be accessible from the heartbeat controller. The public key may be used to encrypt data for the agent.

We get the certificate from the servlet request in a HandshakeInterceptor and store it in a map which is accessible via headerAccessor.getSessionAttributes().

How was this patch tested?

• enabled two way ssl
• checked the value of headerAccessor.getSessionAttributes().get(X509_CERTIFICATE_ATTRIBUTE) from the heartbeatcontroller

[asfgit]

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

[zeroflag]

retest this please

[asfgit]

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

[rlevas]

@mpapirkovskyy , Can you review this? I think you have been working with this interface for a while.

[mpapirkovskyy]

I have few design related discussion points:

1. Why not to allow agent encrypt shared secret itself before storing? data transfer is already encrypted and we will need agent logic anyway. But this is matter of taste.
2. Transient shared secret will add a lot of complexities in server restart process:
   • we should remember that configs are sent to agent when modified, separately from execution commands
   • server send execution commands without configs, configs are propagated from cache on agent
   • server restart will reset and update shared secret, so it won't fit for configs sent earlier anymore
   • this means that we will need additional logic to determine configs with passwords and resend them, as configs don't change from server point of view.

Do we really need transient shared secret? If yes we should consider another key regeneration strategy which will allow to decrypt older configs also.
@zeroflag @rlevas

[rlevas]

@mpapirkovskyy , Thanks for taking a look.

1. Why not to allow agent encrypt shared secret itself before storing? data transfer is already encrypted and we will need agent logic anyway. But this is matter of taste.

This is a great idea. Initially, I was under the impression that the agent wrote the command.json file out to disk before looking at it. However if the agent processes the file (which I think is a newer concept), then going this route would be ideal for many reasons.

2. Transient shared secret will add a lot of complexities in server restart process:
* we should remember that configs are sent to agent when modified, separately from execution commands
* server send execution commands without configs, configs are propagated from cache on agent
* server restart will reset and update shared secret, so it won't fit for configs sent earlier anymore
* this means that we will need additional logic to determine configs with passwords and resend them, as configs don't change from server point of view.

This is a newer concept that I was not aware of. Thanks for pointing it out.

@zeroflag , with this information in mind, let's rethink the architecture.

[rlevas]

Let rethink this...