Failure no such index [.opendistro_security]

[mrvdcsg]

I created a new cluster with certificates signed by my CA. I added nodes.DN and created a separate client cert for admin.dn but no matter what I do I get "Not yet initialized (you may need to run securityadmin)". What am I missing? Do I have to do all custom securityconfig to enable the default security if I bring my own certificate? Does my CA cert need to be defined in caSecrets or can it be included in the TLS secret as the docs say?

spec:
  security:
    tls:  
      transport:  
        generate: false  
        perNode: false  
        secret: 
          name: opensearch-certs # Name of the secret that contains the provided certificate
        # caSecret: # Included in opensearch-certs
        #  name:  # Name of the secret that contains a CA the operator should use
        nodesDn: # List of certificate DNs allowed to connect
          - 'CN=xxxxx'
        adminDn: # List of certificate DNs that should get admin access
          - 'CN=admin-xxxxxx'
      http:
        generate: false 
        secret:
          name:  opensearch-certs
    config:
     adminSecret:
       name: openserach-admin-certs

I have spun my wheels on certificates for 2 days and can't seem to get past this. I tried to run securityadmin.sh manually in one of the pods without success as I couldn't actually find my admin certs. the tls-http and tls-transport certs were both in folders under config so I wasn't sure if the admin ones get put in the opensearch.keystore. Any help is hugely appreciated!

[swoehrl-mw]

Hi @mrvdcsg.
At first glance your configuration looks ok.
Can you please check if the securityconfig-update pod is running? That is a separate job started by the operator to apply the securityconfig. Maybe it has problems. So also check the logs of that pod.

Do I have to do all custom securityconfig to enable the default security if I bring my own certificate?

You can go with the demo securityconfig no problem.

Does my CA cert need to be defined in caSecrets or can it be included in the TLS secret as the docs say?

It can be included in the main secret.

if the admin ones get put in the opensearch.keystore

Nope, the admin certs also just go into a secret as pem files.

[mrvdcsg]

Thank you for your reply @swoehrl-mw ,
Thanks to your suggestion, I was able to resolve my issue. I do have the securityconfig-update pod running. It was complaining that the certificate I was using was also a node certificate which isn't true. However, I noticed that the the user it said it was connecting as was written in a different order than the subject is defined on the certificate itself.

Example:
(What opensearch was attempting to use to do security config)
"CN=admin-opensearch-poc.xyz.com,O=myCompany LLC,L=City,ST=State,C=US"
(What the subject is on my certificate)
subject=/C=US/ST=State/L=City/O=myCompany LLC/CN=admin-opensearch-poc.xyz.com
(What my adminDn looked like before not working)
adminDn: # List of certificate DNs that should get admin access
- 'C=US,ST=State,L=City,O=myCompany LLC,CN=admin-opensearch-poc.xyz.com'
(What my adminDn looked like which works)
adminDn: # List of certificate DNs that should get admin access
- 'CN=admin-opensearch-poc.xyz.com,O=myCompany LLC,L=City,ST=State,C=US'

The configuration for admin_dn needed to match what it was attempting to use in the securityconfig-update pod or it assumed it was a node certificate and failed. Through trial and error I had a good idea of the answers to the other questions but your confirmation helps validate it. Thank you for your reply, I hope this helps someone else who may run into this error!

[swoehrl-mw]

Good to know. Yeah, DN naming can be quite the hassle. As you said, trial and error is often the only good approach.