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

Broker keyfile world-readable #1590

Open
linsomniac opened this issue May 9, 2024 · 0 comments
Open

Broker keyfile world-readable #1590

linsomniac opened this issue May 9, 2024 · 0 comments

Comments

@linsomniac
Copy link

linsomniac commented May 9, 2024

For Confluent Enterprise Support customers, we would strongly advise you to open a Support ticket which will be addressed within your Support contract SLA at https://support.confluent.io

Describe the issue
After an install of Confluent Platform 7.5.3, the /var/lib/private/kafka_broker.key file is world-readable. Looks like the 7.6 branch also has the same issue.

To Reproduce

  • Enable mutual TLS auth (specifically ssl_mutual_auth_enabled)
  • Install kafka broker.
  • See /var/ssl/private/kafka_broker.key permissions

Expected behaviour
It would be nice if the private key file were more restricted.

Inventory File
N/A

Logs
N/A

Environment (please complete the following information):

  • OS: Ubuntu 20.04
  • CP-Ansible Branch: 7.5.3-post
  • Ansible Version ~2.16.0

Additional context
Permissions on the /var/ssl/private/kafka_broker.key file are
publicly readable. Upon further investigation it looks to be
conditional, dependent on
ssl_provided_keystore_and_truststore_remote_src, and if that is
set to false, the keystore is protected.

It seems like in any case you'd want it to be protected.

Specifically, this looks like in 7.5.3 it is related to the setting ssl_mutual_auth_enabled and in 7.6.1 the ssl_provided_keystore_and_trustore_remote_src setting. The block in question is, in 7.6.1-post:

- name: Set Truststore and Keystore File Permissions
  file:
    path: "{{item}}"
    owner: "{{user}}"
    group: "{{group}}"
    mode: '640'
  loop:
    - "{{keystore_path}}"
    - "{{truststore_path}}"
  when: not ( ssl_provided_keystore_and_truststore_remote_src|bool )

In reading the git history (and checking back in 6.2.15-post where the 640 permission was last changed from int to string), I'm under the impression that the "when" condition was blanket applied to the tasks in this role, when it probably shouldn't have been applied to this permission setting. In 7.5.3, this when condition was when: export_certs|bool where export_certs: "{{ssl_mutual_auth_enabled}}"

linsomniac added a commit to linsomniac/cp-ansible that referenced this issue May 9, 2024
This patch is related to issue confluentinc#1590, see that for further discussion.

Permissions on the /var/ssl/private/kafka_broker.key file are
publicly readable.  Upon further investigation it looks to be
conditional, dependent on
`ssl_provided_keystore_and_truststore_remote_src`, and if that is
set to false, the keystore is protected.

It seems like in any case you'd want it to be protected.

This looks like in 7.5.3 it is related to the
setting ssl_mutual_auth_enabled and in 7.6.1 the
ssl_provided_keystore_and_trustore_remote_src setting. The block in
question is, in 7.6.1-post:

- name: Set Truststore and Keystore File Permissions
  file:
    path: "{{item}}"
    owner: "{{user}}"
    group: "{{group}}"
    mode: '640'
  loop:
    - "{{keystore_path}}"
    - "{{truststore_path}}"
  when: not ( ssl_provided_keystore_and_truststore_remote_src|bool )

In reading the git history (and checking back in 6.2.15-post where
the 640 permission was last changed from int to string), I'm under the
impression that the "when" condition was blanket applied to the tasks in
this role, when it probably shouldn't have been applied to this permission
setting. In 7.5.3, this when condition was when: export_certs|bool where
export_certs: "{{ssl_mutual_auth_enabled}}"
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

No branches or pull requests

1 participant