HDDS-2212. Genconf tool should generate config files for secure clust…

[symious]

…er setup

What changes were proposed in this pull request?

• Add the option of "--security" to the tool of "genconf".

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-2212

How was this patch tested?

Manually tested. The usage of the tool is now as follows.

Usage: ozone genconf [-hV] [--security] [--verbose] [-conf=<configurationPath>]
                     [-D=<String=String>]... <path>
Tool to generate template ozone-site.xml
      <path>       Directory path where ozone-site file should be generated.
      --security   Generate security config.
      --verbose    More verbose output. Show the stack trace of the errors.
      -conf=<configurationPath>

  -D, --set=<String=String>

  -h, --help       Show this help message and exit.
  -V, --version    Print version information and exit.

[amaliujia]

@symious is it possible to attach a screenshot for the output of this command flag?

[symious]

@amaliujia Sure. The screen shot is as follows.

[elek]

Thanks the patch @symious. It looks a simple change for me.

My only fear is that I am not sure if the generated config file is enough to start Ozone in secure environment.

For unsecure environment all the required attributes are filled with some reasonable default (like using /tmp for metadata).

I don't know what is a good approach, but the overall goal is to make the configuration easier for the users.

[symious]

Thanks the patch @symious. It looks a simple change for me.

My only fear is that I am not sure if the generated config file is enough to start Ozone in secure environment.

For unsecure environment all the required attributes are filled with some reasonable default (like using /tmp for metadata).

I don't know what is a good approach, but the overall goal is to make the configuration easier for the users.

@elek Thanks for the reply. IMHO, secure config is for advanced users, that they do have the ability and requirement to build a secure cluster. The default config may also mislead the user somehow.

[adoroszlai]

My only fear is that I am not sure if the generated config file is enough to start Ozone in secure environment.

Thanks @elek for sharing your thoughts. I also had the same doubt: most of the security-related configs are empty by default. That's why I pinged @dineshchitlangia, the reporter of this task, for review, in the hope that we can clarify the intended scope.

[symious]

@elek @adoroszlai Thanks for the reply. I think it will be good to wait for @dineshchitlangia 's reply. Meanwhile, I can try to build a secure cluster and fill in the required configs.

[dineshchitlangia]

@symious Thanks for working on this.

I also reviewed thoughts from @adoroszlai and @elek .

My thoughts on this are:

1. We certainly need to make it easier for users as @elek mentioned.
2. I think we can start by generating a security config template and that is why I suggested the inline change.
3. We can file another jira to generate conf with predefined security config values(if at all possible).
4. Add test for security template in TestGenerateOzoneRequiredConfigurations

[dineshchitlangia]

Suggested change

	@Option(names = "--security", description = "Generate security config.")
	@Option(names = "--security", description = "Generates security config template, update template with proper values before use.")

[symious]

@dineshchitlangia Thanks for the review. Added a new commit with the following update:

1. Added the unit test for security config generation, and update the command option description.
2. After checking the configurations with the tag of "SECURITY", I found a lot of unrelated or fundamental configs that users shouldn't use usually, such ashdds.x509.signature.algorithm. And then I walk through the document of Ozone Security, I found that all configs are related to kerberos, so my idea is to add a new tag named as "KERBEROS" to track the common used security configs.
3. After checking the docker file of ozonesecure, I found that the principal and keytab are coordinated with the KDC server, which means the KDC server and the keytab file has to be generated and prepared before we start ozone cluster, so the configs must be updated manually unless we set up a KDC server and update the keytab files for the users, which I think is quite strange.

In docker, flokkr/issuer helps to initial KDC and update the keytab files, so for testing, it would be quite convenient for the user to just use docker. And for genconf --security, I think it's mainly for the users who has Kerberos set up already and want to fill the required security configs template for a productive secure cluster.

[dineshchitlangia]

@symious Thank you for updating the PR.
Minor changes requested inline.

@elek what are your thoughts on the new KERBEROS tag? For me, it is fine to add the new tag as it is easy to identify which configs to deal with when you want to implement kerberos but I would like to hear your opinion too.

[elek]

+1 let's merge it after a green build

I asked others on the community meeting and the agreement was that it's better to have this even if it doesn't generate all the required configs (keytabs should be provided, etc...)

Comments from @dineshchitlangia are adressed as far as I see, the only thing what we need is a green build...

[symious]

@elek Thanks for the review, I just found the other comment @dineshchitlangia mentioned above, let me add the "SECURITY" tag, too.

[dineshchitlangia]

Thanks for making the changes. +1

[elek]

Merging it now. Thanks the update @symious and the review @dineshchitlangia and @adoroszlai