Install Kibana per tenant #3348
Conversation
pkg/controller/logstorage/elastic/external_elastic_controller.go
Outdated
Show resolved
Hide resolved
| } | ||
| }) | ||
|
|
||
| It("should support an external kibana endpoint", func() { |
There was a problem hiding this comment.
It seems like this should still be a valid test. We'll still need to "support an external kibana endpoint".
| @@ -60,7 +60,7 @@ type KibanaPodSpec struct { | |||
| type KibanaContainer struct { | |||
| // Name is an enum which identifies the Kibana Deployment container by name. | |||
| // Supported values are: kibana | |||
| // +kubebuilder:validation:Enum=kibana | |||
| // +kubebuilder:validation:Enum=kibana;challenger | |||
There was a problem hiding this comment.
I think we should have validation that challenger is not allowed in non-multi-tenent clusters.
| @@ -351,6 +386,20 @@ func (r *UserController) createUserLogin(ctx context.Context, elasticEndpoint st | |||
| return nil | |||
| } | |||
|
|
|||
| func (r *UserController) createUser(ctx context.Context, elasticEndpoint string, user *utils.User, reqLogger logr.Logger) error { | |||
There was a problem hiding this comment.
I was looking to see if we needed both createUser and createUserLogin and I think the answer is yes but it looks like we could have createUserLogin call createUser, that should allow removing some duplicate code.
| if err = r.client.Update(ctx, &t); err != nil { | ||
| logger.Error(err, "Failed to remove user cleanup finalizer from tenant") | ||
| } | ||
| if deletedUsers > 0 { |
There was a problem hiding this comment.
I guess this is maintaining the same behavior as before but it seems like we should only remove the finalizer if all 3 users have been removed. I think if removal of any of them failed then the finalizer should remain. WDYT?
| @@ -290,6 +290,10 @@ func (h *NetworkPolicyHelper) ComplianceReporterSourceEntityRule() v3.EntityRule | |||
| return CreateSourceEntityRule(h.namespace("tigera-compliance"), "compliance-reporter") | |||
| } | |||
|
|
|||
| func (h *NetworkPolicyHelper) KibanaEntityRule() v3.EntityRule { | |||
There was a problem hiding this comment.
I think this function is only used for Multi-tenant kibana and in that case doesn't this rule need to use the tenant namespace?
Description
Kibana will be installed per tenant using ECK operator. Both Kibana and ECK will be deployed by external elastic search controller. ECK operator will be configured to watch in all namespaces. In a tenant namespace we will create a Kibana CR that contains an additional container "challenger". Challenger connects to external elastic via mTLS, while Kibana per tenant connects to Elastic using locahost and no TLS. An kibana admin user will be created in external elasticsearch and referenced via SecureSettings field from the Kibana spec. This secret will contain only elasticsearch.password that in mounted by kibana keystore container at startup. This secret will be created by users controller.
Dashboards and ES Proxy will need to access kibana per tenant.
This PR also adds the ability to install or not install kibana per tenant.
For PR author
make gen-filesmake gen-versionsFor PR reviewers
A note for code reviewers - all pull requests must have the following:
kind/bugif this is a bugfix.kind/enhancementif this is a a new feature.enterpriseif this PR applies to Calico Enterprise only.