generate certificates internally. The recommended approach is to supply your own CA, or  create an entirely new CA specifically for each ELK stack to provide as much isolation as  possible in clusters using multiple ELK stacks. If a malicious user has access to the CA  key-pair used for each ELK deployment, it’s possible for that user to gain access to the other  ELK stacks. If the cluster is a ‘trusted environment’ model, then this may not be a problem, but  for other clusters where security and isolation of log data is a key requirement, it is  recommended to use a new CA key-pair for each ELK deployment. To create a dedicated CA for each ELK stack use the  openssl  command in Example 5-18  replacing the subject details if necessary. This will output a ca.crt and ca.key file to your local machine. Run the command in  Example 5-20 to create a new key-pair Kubernetes Secret from these files. This secret can be used later when deploying ELK. To specify your own CA to use when deploying additional ELK stacks, three requirements  must be met: If the keys are stored locally, run the command in Example 5-20 to create a new secret,  replacing  <path-to-file>  with the file path of the files. Alternatively, Example 5-21 shows the YAML for a sample secret using defined CA  certificates. You’ll need to  paste the contents of the  my_ca.crt  and  my_ca.key  in the YAML  definition in your preferred editor. Example 5-18 Creating a new CA using openssl Example 5-19 Create secret from new CA Example 5-20 Create secret from custom CA Example 5-21 YAML definition for my-ca-secret openssl req -newkey rsa:4096 -sha256 -nodes -keyout ca.key -x509 -days 36500 -out  ca.crt -subj "/C=US/ST=NewYork/L=Armonk/O=IBM Cloud Private/CN=www.ibm.com" kubectl -n elk create secret generic elk-ca-secret --from-file=ca.crt  --from-file=ca.key kubectl -n elk create secret generic elk-ca-secret  --from-file=<path-to-file>/my_ca.crt --from-file=<path-to-file>/my_ca.key apiVersion: v1 kind: Secret metadata: name: my-ca-secret type: Opaque data: my_ca.crt: ... my_ca.key: ... GLYPH<SM590000> The CA must be stored in a Kubernetes secret. GLYPH<SM590000> The secret must exist in the namespace to which the ELK stack is deployed. GLYPH<SM590000> The contents of the certificate and its secret key must be stored in separately named fields  (or keys) within the Kubernetes secret. 192  IBM Cloud Private System Administrator’s Guide