- Elastic Cloud on Kubernetes:
- Overview
- Quickstart
- Operating ECK
- Orchestrating Elastic Stack applications
- Run Elasticsearch on ECK
- Node configuration
- Volume claim templates
- Storage recommendations
- Transport settings
- Virtual memory
- Settings managed by ECK
- Secure settings
- Custom configuration files and plugins
- Init containers for plugin downloads
- Update strategy
- Pod disruption budget
- Nodes orchestration
- Advanced Elasticsearch node scheduling
- Create automated snapshots
- Remote clusters
- Readiness probe
- Pod PreStop hook
- Elasticsearch autoscaling
- JVM heap dumps
- Security Context
- Run Kibana on ECK
- Run APM Server on ECK
- Run standalone Elastic Agent on ECK
- Run Fleet-managed Elastic Agent on ECK
- Run Elastic Maps Server on ECK
- Run Enterprise Search on ECK
- Run Beats on ECK
- Secure the Elastic Stack
- Access Elastic Stack services
- Customize Pods
- Manage compute resources
- Autoscaling stateless applications
- Upgrade the Elastic Stack version
- Run Elasticsearch on ECK
- Advanced topics
- Reference
- API Reference
- agent.k8s.elastic.co/v1alpha1
- apm.k8s.elastic.co/v1
- apm.k8s.elastic.co/v1beta1
- beat.k8s.elastic.co/v1beta1
- common.k8s.elastic.co/v1
- common.k8s.elastic.co/v1beta1
- elasticsearch.k8s.elastic.co/v1
- elasticsearch.k8s.elastic.co/v1beta1
- enterprisesearch.k8s.elastic.co/v1
- enterprisesearch.k8s.elastic.co/v1beta1
- kibana.k8s.elastic.co/v1
- kibana.k8s.elastic.co/v1beta1
- maps.k8s.elastic.co/v1alpha1
- Glossary
- Third-party dependencies
- API Reference
- Release highlights
- 2.3.0 release highlights
- 2.2.0 release highlights
- 2.1.0 release highlights
- 2.0.0 release highlights
- 1.9.1 release highlights
- 1.9.0 release highlights
- 1.8.0 release highlights
- 1.7.1 release highlights
- 1.7.0 release highlights
- 1.6.0 release highlights
- 1.5.0 release highlights
- 1.4.1 release highlights
- 1.4.0 release highlights
- 1.3.2 release highlights
- 1.3.1 release highlights
- 1.3.0 release highlights
- 1.2.2 release highlights
- 1.2.1 release highlights
- 1.2.0 release highlights
- 1.1.2 release highlights
- 1.1.1 release highlights
- 1.1.0 release highlights
- 1.0.1 release highlights
- 1.0.0 release highlights
- 1.0.0-beta1 release highlights
- Release notes
- Elastic Cloud on Kubernetes version 2.3.0
- Elastic Cloud on Kubernetes version 2.2.0
- Elastic Cloud on Kubernetes version 2.1.0
- Elastic Cloud on Kubernetes version 2.0.0
- Elastic Cloud on Kubernetes version 1.9.1
- Elastic Cloud on Kubernetes version 1.9.0
- Elastic Cloud on Kubernetes version 1.8.0
- Elastic Cloud on Kubernetes version 1.7.1
- Elastic Cloud on Kubernetes version 1.7.0
- Elastic Cloud on Kubernetes version 1.6.0
- Elastic Cloud on Kubernetes version 1.5.0
- Elastic Cloud on Kubernetes version 1.4.1
- Elastic Cloud on Kubernetes version 1.4.0
- Elastic Cloud on Kubernetes version 1.3.2
- Elastic Cloud on Kubernetes version 1.3.1
- Elastic Cloud on Kubernetes version 1.3.0
- Elastic Cloud on Kubernetes version 1.2.2
- Elastic Cloud on Kubernetes version 1.2.1
- Elastic Cloud on Kubernetes version 1.2.0
- Elastic Cloud on Kubernetes version 1.1.2
- Elastic Cloud on Kubernetes version 1.1.1
- Elastic Cloud on Kubernetes version 1.1.0
- Elastic Cloud on Kubernetes version 1.0.1
- Elastic Cloud on Kubernetes version 1.0.0
- Elastic Cloud on Kubernetes version 1.0.0-beta1
Restrict cross-namespace resource associations
editRestrict cross-namespace resource associations
editThis section describes how to restrict associations that can be created between resources managed by ECK.
When using the elasticsearchRef
field to establish a connection to Elasticsearch from Kibana, APM Server, Enterprise Search, or Beats resources, by default the association is allowed as long as both resources are deployed to namespaces managed by that particular ECK instance. The association will succeed even if the user creating the association does not have access to one of the namespaces or the Elasticsearch resource.
The enforcement of access control rules for cross-namespace associations is disabled by default. Once enabled, it only enforces access control for resources deployed across two different namespaces. Associations between resources deployed in the same namespace are not affected.
Associations are allowed as long as the ServiceAccount
used by the associated resource can execute HTTP GET
requests against the referenced Elasticsearch object.
ECK automatically removes any associations that do not have the correct access rights. If you have existing associations, do not enable this feature without creating the required Roles
and RoleBindings
as described in the following sections.
To enable the restriction of cross-namespace associations, start the operator with the --enforce-rbac-on-refs
flag.
-
Create a
ClusterRole
to allow HTTPGET
requests to be run against Elasticsearch objects:apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: elasticsearch-association rules: - apiGroups: - elasticsearch.k8s.elastic.co resources: - elasticsearches verbs: - get
-
Create a
ServiceAccount
and aRoleBinding
in the Elasticsearch namespace to allow any resource using theServiceAccount
to associate with the Elasticsearch cluster:> kubectl create serviceaccount associated-resource-sa
apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: allow-associated-resource-from-remote-namespace namespace: elasticsearch-ns roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: elasticsearch-association subjects: - kind: ServiceAccount name: associated-resource-sa namespace: associated-resource-ns
-
Set the
serviceAccountName
field in the associated resource to specify whichServiceAccount
is used to create the association:apiVersion: kibana.k8s.elastic.co/v1 kind: Kibana metadata: name: associated-resource namespace: associated-resource-ns spec: ... elasticsearchRef: name: "elasticsearch-sample" namespace: "elasticsearch-ns" # Service account used by this resource to get access to an Elasticsearch cluster serviceAccountName: associated-resource-sa
In this example, associated-resource
can be of any Kind
that requires an association to be created, for example Kibana
or ApmServer
.
You can find a complete example in the ECK GitHub repository.
If the serviceAccountName
is not set, ECK uses the default service account assigned to the pod by the Service Account Admission Controller.
The associated resource associated-resource
is now allowed to create an association with any Elasticsearch cluster in the namespace elasticsearch-ns
.