Add single-user authentication

O-Bezimo commented 1 year ago

Q	A
Bug fix?	no
New feature?	yes
API breaks?	no
Deprecations?	no
Related tickets	fixes #X, partially #Y, mentioned in #Z
License	Apache 2.0

What's in this PR?

Our objective is to add the Single-User authentication in addition to the OIDC and LDAP authentication methods.

We added a SingleUserConfiguration object in the NifiCluster ressource. The options are the following:

Enabled boolean: set to true to add the according single-user configuration blocs in the nifi.properties template and the login_identity_provider template.
SecretRef SecretReference: reference to a kubernetes secret containing the desired username and password.
AuthorizerEnabled bool: set to true to use the single-user-authorizer. Set to false to use the default managed-authorizer.

We also added the reference to the SingleUserConfiguration in the helm folder.

Why?

If neither OIDC or LDAP are configured, nifi forces a certificate authentication on all HTTP/HTTPS certificates. We need another option so that we can have functionnal healthchecks on our loadbalancer generated by the ingress-controller.

Additional context

We tested the code with an integration cluster hosted on gcp and telepresence as a proxy for our modified operator.

We also proofed some error cases:

if SingleUserConfiguration.Enabled is false and SingleUserConfiguration.AuthorizerEnabled is true: don't configure the authorizer
if SecretRef is empty: use auto generated username and password that would appear in the logs

Checklist

[x] Implementation tested
[x] Error handling code meets the guideline
[x] Logging code meets the guideline
[x] User guide and development docs updated (if needed)
[x] Append changelog with changes

juldrixx commented 1 year ago

@mh013370 Should secret keys be supplied in the operator configuration or forced as now?

O-Bezimo commented 1 year ago

@mh013370 Should secret keys be supplied in the operator configuration or forced as now?

Secret keys are supplied if singleUserConfiguration->enabled is true and if singleUserConfiguration->secretRef is not given in the nificluster.yml configuration. If enabled is true and secretRef is declared and exists in the cluster with a username and password, the operator will use these instead as credentials and add it in the login_identity_providers file.

mh013370 commented 1 year ago

@mh013370 Should secret keys be supplied in the operator configuration or forced as now?

@mh013370 Should secret keys be supplied in the operator configuration or forced as now?

Secret keys are supplied if singleUserConfiguration->enabled is true and if singleUserConfiguration->secretRef is not given in the nificluster.yml configuration. If enabled is true and secretRef is declared and exists in the cluster with a username and password, the operator will use these instead as credentials and add it in the login_identity_providers file.

If SingleUserConfiguration.SecretRef is optional, then it should be expressed as such in the spec by using a pointer (allowing you to check for nil) and adding the // +optional kubebuilder annotation.

mh013370 commented 1 year ago

Why are there a whole new set of unversioned docs?

O-Bezimo commented 1 year ago

@mh013370 Should secret keys be supplied in the operator configuration or forced as now?

@mh013370 Should secret keys be supplied in the operator configuration or forced as now?

Secret keys are supplied if singleUserConfiguration->enabled is true and if singleUserConfiguration->secretRef is not given in the nificluster.yml configuration. If enabled is true and secretRef is declared and exists in the cluster with a username and password, the operator will use these instead as credentials and add it in the login_identity_providers file.

If SingleUserConfiguration.SecretRef is optional, then it should be expressed as such in the spec by using a pointer (allowing you to check for nil) and adding the // +optional kubebuilder annotation.

Thank you for your answer, the modification have been made

O-Bezimo commented 1 year ago

@mh013370 Should secret keys be supplied in the operator configuration or forced as now?

@mh013370 Should secret keys be supplied in the operator configuration or forced as now?

Secret keys are supplied if singleUserConfiguration->enabled is true and if singleUserConfiguration->secretRef is not given in the nificluster.yml configuration. If enabled is true and secretRef is declared and exists in the cluster with a username and password, the operator will use these instead as credentials and add it in the login_identity_providers file.

If SingleUserConfiguration.SecretRef is optional, then it should be expressed as such in the spec by using a pointer (allowing you to check for nil) and adding the // +optional kubebuilder annotation.

A pointer is added to Secret ref and the empty checks are made with nil as of now. An optional annotation is added and the same is made to a secretKeys struct allowing the final user to change the username and password keys. They will default to "username" and "password" if nil and the according information are added in the documentation and in the helm folder.

O-Bezimo commented 1 year ago

Why are there a whole new set of unversioned docs?

I switched the 1.3 versioned docs to unversioned which was a mistake. Since then I deleted it and moved the modifications in ./site/docs.

gitguardian[bot] commented 1 year ago

⚠️ GitGuardian has uncovered 2 secrets following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secrets in your pull request

| GitGuardian id | Secret | Commit | Filename | | | -------------- | ------------------------- | ---------------- | --------------- | -------------------- | | [-](https://dashboard.gitguardian.com/incidents/secrets) | Generic Password | b2f5f75cd464c31aeccab5f9154c5b913671ea35 | pkg/resources/nifi/pod.go | [View secret](https://github.com/konpyutaika/nifikop/commit/b2f5f75cd464c31aeccab5f9154c5b913671ea35#diff-b4b5c76629e53e3eba760d75c39131c0L486) | | [-](https://dashboard.gitguardian.com/incidents/secrets) | Generic Password | 0978cc6bee80e6e9474427e41226cd75f4e8e1fd | pkg/resources/nifi/pod.go | [View secret](https://github.com/konpyutaika/nifikop/commit/0978cc6bee80e6e9474427e41226cd75f4e8e1fd#diff-b4b5c76629e53e3eba760d75c39131c0L486) |

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code. 2. Replace and store your secrets safely. [Learn here](https://blog.gitguardian.com/secrets-api-management?utm_source=product&utm_medium=GitHub_checks&utm_campaign=check_run_comment) the best practices. 3. Revoke and [rotate these secrets](https://docs.gitguardian.com/secrets-detection/detectors/generics/generic_password#revoke-the-secret?utm_source=product&utm_medium=GitHub_checks&utm_campaign=check_run_comment). 4. If possible, [rewrite git history](https://blog.gitguardian.com/rewriting-git-history-cheatsheet?utm_source=product&utm_medium=GitHub_checks&utm_campaign=check_run_comment). Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data. To avoid such incidents in the future consider - following these [best practices](https://blog.gitguardian.com/secrets-api-management/?utm_source=product&utm_medium=GitHub_checks&utm_campaign=check_run_comment) for managing and storing secrets including API keys and other credentials - install [secret detection on pre-commit](https://docs.gitguardian.com/ggshield-docs/integrations/git-hooks/pre-commit?utm_source=product&utm_medium=GitHub_checks&utm_campaign=check_run_comment) to catch secret before it leaves your machine and ease remediation.

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.

Our GitHub checks need improvements? Share your feedbacks!}

konpyutaika / nifikop