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. 

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" 

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. 

kubectl -n elk create secret generic elk-ca-secret --from-file=ca.crt --from-file=ca.key 

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: 

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. 

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. 

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 

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. 

apiVersion: v1 kind: Secret metadata: name: my-ca-secret type: Opaque data: my_ca.crt: ... my_ca.key: ... 

