search

cetic / helm-nifi

Helm Chart for Apache Nifi
Apache License 2.0
215 stars 225 forks source link

Use external CA instead of nifi-ca #232

Closed bmgante closed 2 years ago

bmgante commented 2 years ago

Hi, Does this helm support to install an external valid certificate (full chain) in a secure cluster instead of having to user nifi-ca which will always throw security warnings on browser? If yes, would you mind to provide some guidance?

Thanks

banzo commented 2 years ago

@bmgante there might be some info on that in #218

bmgante commented 2 years ago

Hi @banzo what about generating the certificate externally and just import/install it on NiFi nodes without using nifi-ca? Is it possible?

Regarding https://github.com/cetic/helm-nifi/pull/218 is there any ETA to have it available on helm chart and can we use that feature with chart v0.7.8 and nifi 1.12.1?

gforeman02 commented 2 years ago

@bmgante, this was how I was able to get clustered Nifi working with an external CA.

values.yaml settings:

replicaCount: 3

...

secrets:
- name: <your secrets name>
  keys:
    - nifi-0.nifi-headless.<your namespace>.svc.cluster.local.jks
    - nifi-1.nifi-headless.<your namespace>.svc.cluster.local.jks
    - nifi-2.nifi-headless.<your namespace>.svc.cluster.local.jks
    - truststore.jks
    - config.json
    - admin.crt
    - admin.key
  mountPath: /opt/nifi/nifi-current/config-data/certs/

Note: The config.json file should have keyStorePassword, keyPassword, and trustStorePassword set.

properties:
  isNode: true

...

safetyValve:
  nifi.security.keystoreType: jks
  nifi.security.keystore: ${NIFI_HOME}/config-data/certs/${FQDN}.jks
  nifi.security.keystorePasswd: $(jq -r .keyStorePassword ${NIFI_HOME}/config-data/certs/config.json)
  nifi.security.keyPasswd: $(jq -r .keyPassword ${NIFI_HOME}/config-data/certs/config.json)
  nifi.security.truststoreType: jks
  nifi.security.truststore: ${NIFI_HOME}/config-data/certs/truststore.jks
  nifi.security.truststorePasswd: $(jq -r .trustStorePassword ${NIFI_HOME}/config-data/certs/config.json)
bmgante commented 2 years ago

Hi @gforeman02 Thanks so much for your input. So if i understood it properly:

  1. Disable nifi-ca on values.yaml
  2. Update sts.secrets, properties.isNode and properties.safetyValue accordingly to your post;

How do you transfer admin.crt, admin.key and config.json to the pods? Can you provide an example of your config.json (without credentials)?

Thanks again for your support.

gforeman02 commented 2 years ago

@bmgante all the files can be posted as a kubernetes opaque secret:

kubectl create secret generic <your secrets name> \
--from-file=admin.crt=/path/to/admin.crt \
--from-file=admin.key=/path/to/admin.key \
...

The config.json is just:

{
  "keystorePassword": "your_password", 
  "keyPassword": "your_password",
  "trustStorePassword": "your_password"
}
bmgante commented 2 years ago

@gforeman02 From my understanding we must create first the secret object through command like or yaml file. I believe that create a secret.yaml for this helm chart would be the right option, did you create it on your side? If yes, would you mind to share the code? 

apiVersion: v1

kind: Secret

metadata:
  name: {{ template "apache-nifi.fullname" . }}
  namespace: {{ .Release.Namespace | quote }}
  labels:
    app: {{ include "apache-nifi.name" . | quote }}
    chart: "{{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}"
    release: {{ .Release.Name | quote }}
    heritage: {{ .Release.Service | quote }}

type: Opaque

data:
  nifi-0.nifi-headless.{{ .Release.Namespace | quote }}.svc.cluster.local.jks: ???
  nifi-1.nifi-headless.{{ .Release.Namespace | quote }}.svc.cluster.local.jks: ???
  nifi-2.nifi-headless.{{ .Release.Namespace | quote }}.svc.cluster.local.jks: ???
  truststore.jks: ???
  admin.crt: ???
  admin.key: ???

stringData:
    config.json: |
    {
      "keystorePassword": "your_password", 
      "keyPassword": "your_password",
      "trustStorePassword": "your_password"
    }

I am just giving my first steps with kubernetes, sorry for these questions :)

bugslifesolutions commented 2 years ago

@bmgante Did you make any progress with your approach?

bmgante commented 2 years ago

Not yet, I was hoping @gforeman02 could confirm if he had created a secret.yaml (and share it if possível) to include in the helm chart or if he just created the secret object manually and deployed the helm chart after that.

bmgante commented 2 years ago

I have been trying but i struggled understanding how to generate the following objects to put them after in the k8s secret:

@gforeman02 would you mind please to provide some guidance?

Thanks in advance

gforeman02 commented 2 years ago

@bmgante I addressed your original question. The admin.crt/admin.key are client certificates but are not required -- you can omit them. Information for creating a truststore file containing your CA and the keystores is readily available online.

bmgante commented 2 years ago

Hi @gforeman02 Thanks for your help on this. I was almost able to configure the secret with the keystore and trustore. However i have now a different issue related to the internal names of nodes. While my certificate name is "nifi.namespace.xxx.net" (dns of load balancer to access webui), seems that the internal names of pods need to be included in the certificate as alternative names.

The problem is that cluster.local is a domain that cannot be certified by the external CA we are using (sectigo). Do you know if it is possible to overpass this limitation? wondering if it could be possible to do not need to specifcy internal node names in certificate or if it is possible to change the internal node names in k8s for something xxx.net which is a domain CA can certify.

Thanks

gforeman02 commented 2 years ago

@bmgante contact Sectigo.

bmgante commented 2 years ago

@gforeman02 cluster.local is not really possible to get sectigo to certify cluster.local domain indeed, i´ve already confirmed. Just wondering if you are aware of any other approach or workaround that could be done to address this limitation. Thanks