You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@pulsar.apache.org by GitBox <gi...@apache.org> on 2022/01/27 19:31:06 UTC

[GitHub] [pulsar-helm-chart] csthomas1 opened a new pull request #219: Feature/pulsar manager v0.2.0 with jwt setup admin account creation

csthomas1 opened a new pull request #219:
URL: https://github.com/apache/pulsar-helm-chart/pull/219

Fixes #133 #108 #86 #31

### Motivation

The docker image for Pulsar Manager v0.2.0 includes support for JWT-based configurations, so long as the appropriate environment variables are specified:
- JWT_TOKEN
- PRIVATE_KEY/PUBLIC_KEY -or- SECRET_KEY

The k8s secrets that can populate each of the above environment variables are created by the 'prepare_helm_release.sh' script when it is run prior to installation of the helm chart. Unfortunately, the helm chart doesn't current provide a way to directly expose these secrets to the Pulsar Manager deployment. Instead, it requires that these values be separately set in the "configData" map of the "pulsar_manager" section, which creates the opportunity for them to go out of sync. Further, it exposes in clear text potentially sensitive values (the superuser token and the key material) alongside in the ConfigMap of other environment settings.

Pulsar Manager v0.2.0 has also introduced a user management capability that is enabled by default, and requires that the initial admin/superuser account be created via web service call (see https://github.com/apache/pulsar-manager/blob/master/README.md).

Finally, the current helm chart mistakenly conflates the Pulsar Manager admin user's credentials with those of the Postgres user account used to establish a connection to the Pulsar Manager's internal database -- it mounts the admin user's credentials secret to the "USERNAME" and "PASSWORD" environment variables, despite the fact that these control only the datasource connection parameters as described above. Further, with the current secret mounting approach, changing the admin credentials actually breaks the Pulsar Manager deployment because the pulsar database credentials are hardcoded in the postgres db initialization script.

The changes included in this PR do the following:
1. Enable mounting of the appropriate JWT and key secrets to the appropriate environment variables when JWT authentication is enabled;
2. Automatically (when requested) creates the initial admin account via web service call on container startup. This initial account will be configured with the credentials contained in the manager's admin secret.
3. The manager's admin secret will no longer be used to set the USERNAME and PASSWORD environment variables for reasons described above; hence, changing the admin secret will now correctly only affect the credentials recognized as the default login to the Pulsar Manager and will no longer break the connection to Pulsar Manager's internal database.

### Modifications

1. In charts/pulsar/values.yaml:
- Added auth.superUsers type "manager," which defaults to blank. Setting a value here determines the JWT secret (generated by the prepare_helm_release.sh script) that will be used by the Pulsar Manager to communicate with the Pulsar brokers when JWT authentication is enabled.
- Added pulsar_manager.autoCreateAdminAccount, which defaults to true. When this value is set to true, a sidecar will be added to the Pulsar Manager pod that will create the admin's account from the configured credentials when the container launches.
- Added 'USERNAME' and 'PASSWORD' with values of pulsar/pulsar to pulsar_manager.configData, since these values currently must agree with the hardcoded values in the database initialization script
2. In charts/pulsar/templates/pulsar-manager-deployment.yaml:
- REMOVED the mounts of the pulsar admin secret to the USERNAME and PASSWORD environment variables.
- ADDED env secretKeyRefs for JWT_TOKEN to the "manager" superUser token when jwt authentication is enabled
- ADDED env file path value for SECRET_KEY when jwt authentication is enabled and jwt.usingSecretKey is true
- ADDED env file path value for PRIVATE_KEY and PUBLIC_KEY when jwt authentication is enabled and jwt.usingSecretKey is false
- ADDED volume mount for pulsar-manager-keys when jwt authentication is enabled
- ADDED volume for the symmetric token signing key when jwt authentication is enabled and jwt.usingSecretKey is true
- ADDED volume for the asymmetric token signing key when jwt authentication is enabled and jwt.usingSecretKey is false
- ADDED sidecar container to initialize admin user account when pulsar_manager.autoCreateAdminAccount is true.
Upon launch, the sidecar will attempt to curl the pulsar-manager's main page every 3 seconds until it receives a successful status. At that point, it will perform the procedure described in the pulsar manager README.md (get a CSRF token, then
make another service call to create the admin account). It will then sleep forever.
### Verifying this change

- [ ] Make sure that the change passes the CI checks.

--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscribe@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org