fix(merge): Merges Dedicated user groups with Clustered setup
Jason Stirnaman
commit
f85e341d75
|
|
@ -50,7 +50,7 @@ related:
|
|||
---
|
||||
|
||||
Use the [`influxctl` CLI](/influxdb/cloud-dedicated/reference/cli/influxctl/)
|
||||
or the [Management HTTP API](influxdb/cloud-dedicated/api/management/) to create a [database token](/influxdb/cloud-dedicated/admin/tokens/database/) with permissions for reading and writing data in your {{< product-name omit=" Clustered" >}} cluster.
|
||||
or the [Management HTTP API](/influxdb/cloud-dedicated/api/management/) to create a [database token](/influxdb/cloud-dedicated/admin/tokens/database/) with permissions for reading and writing data in your {{< product-name omit=" Clustered" >}} cluster.
|
||||
|
||||
{{< tabs-wrapper >}}
|
||||
{{% tabs %}}
|
||||
|
|
@ -435,4 +435,4 @@ curl \
|
|||
|
||||
{{% /code-placeholders %}}
|
||||
{{% /code-tab-content %}}
|
||||
{{< /code-tabs-wrapper >}}
|
||||
{{< /code-tabs-wrapper >}}
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ related:
|
|||
---
|
||||
|
||||
Use the [`influxctl` CLI](/influxdb/cloud-dedicated/reference/cli/influxctl/)
|
||||
or the [Management HTTP API](influxdb/cloud-dedicated/api/management/)
|
||||
or the [Management HTTP API](/influxdb/cloud-dedicated/api/management/)
|
||||
to delete a database token from your {{< product-name omit=" Clustered" >}} cluster.
|
||||
|
||||
{{< tabs-wrapper >}}
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ related:
|
|||
---
|
||||
|
||||
Use the [`influxctl` CLI](/influxdb/cloud-dedicated/reference/cli/influxctl/)
|
||||
or the [Management HTTP API](influxdb/cloud-dedicated/api/management/)
|
||||
or the [Management HTTP API](/influxdb/cloud-dedicated/api/management/)
|
||||
to list database tokens in your {{< product-name omit=" Clustered" >}} cluster.
|
||||
|
||||
[List database tokens](#list-database-tokens)
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ related:
|
|||
---
|
||||
|
||||
Use the [`influxctl` CLI](/influxdb/cloud-dedicated/reference/cli/influxctl/)
|
||||
or the [Management HTTP API](influxdb/cloud-dedicated/api/management/)
|
||||
or the [Management HTTP API](/influxdb/cloud-dedicated/api/management/)
|
||||
to update a database token's permissions {{< product-name omit=" Clustered" >}} cluster.
|
||||
|
||||
{{< tabs-wrapper >}}
|
||||
|
|
|
|||
|
|
@ -0,0 +1,99 @@
|
|||
---
|
||||
title: Manage users
|
||||
seotitle: Manage users and permissions in InfluxDB Cloud Dedicated
|
||||
description: >
|
||||
Manage users and access to resources in your InfluxDB Cloud Dedicated cluster.
|
||||
Assign user groups for role-based access control and security.
|
||||
menu:
|
||||
influxdb_cloud_dedicated:
|
||||
parent: Administer InfluxDB Cloud
|
||||
weight: 101
|
||||
influxdb/cloud-dedicated/tags: [user groups]
|
||||
related:
|
||||
- /influxdb/cloud-dedicated/reference/internals/security/
|
||||
- /influxdb/cloud-dedicated/admin/tokens/
|
||||
---
|
||||
|
||||
Manage users and access to resources in your {{% product-name %}} cluster.
|
||||
|
||||
By assigning users to different groups based on the level of access they need,
|
||||
you can minimize unnecessary access and reduce the risk of inadvertent
|
||||
actions.
|
||||
User groups associate access privileges with user attributes--an important part of the
|
||||
Attribute-Based Access Control (ABAC) security model which grants access based on
|
||||
user attributes, resource types, and environment context.
|
||||
|
||||
- [Available user groups](#available-user-groups)
|
||||
- [Manage users](#manage-users)
|
||||
- [Assign a user to a different group](#assign-a-user-to-a-different-group)
|
||||
- [Invite a user to your account](#invite-a-user-to-your-account)
|
||||
|
||||
### Available user groups
|
||||
|
||||
In {{% product-name %}}, users have "management" roles, such as creating and
|
||||
deleting databases, viewing resource information, and provisioning
|
||||
[database tokens](/influxdb/cloud-dedicated/admin/tokens/database/) for reading and writing data.
|
||||
|
||||
A user can belong to the following groups, each with predefined privileges:
|
||||
|
||||
<!-- Question: what are the "certain resources" below? -->
|
||||
|
||||
- **Admin**: Read and write permissions on all resources.
|
||||
- **Member**: Read permission on certain resources and create permission for
|
||||
database tokens; members can't delete or create databases or management tokens.
|
||||
- **Auditor**: Read permission on all resources; auditors can't modify resources.
|
||||
|
||||
{{% note %}}
|
||||
#### Existing users are Admin by default
|
||||
|
||||
With the release of user groups for {{% product-name %}}, all existing users
|
||||
in your account are initially assigned to the Admin group, retaining full
|
||||
access to resources in your cluster.
|
||||
{{% /note %}}
|
||||
|
||||
### Manage users
|
||||
|
||||
InfluxData uses Auth0 to create user accounts and assign users to groups
|
||||
in {{% product-name %}}.
|
||||
|
||||
### Assign a user to a different group
|
||||
|
||||
To assign existing users in your account to different
|
||||
groups, [contact InfluxData support](https://support.influxdata.com/s/login/)
|
||||
and provide the list of users and the desired [user groups](#available-user-groups)
|
||||
for each.
|
||||
|
||||
### Invite a user to your account
|
||||
|
||||
For new users that you want to add to your account, the InfluxData Support Team
|
||||
configures invitations with the attributes and groups that you specify.
|
||||
|
||||
<!-- Question: cluster admins shouldn't use `influctl user invite` https://github.com/influxdata/docs-v2/blob/dddf699722bc9e2ba33c4ea9f34673454f3164a5/content/influxdb/cloud-dedicated/reference/cli/influxctl/user/invite.md
|
||||
How should we communicate this? -->
|
||||
|
||||
1. [Contact InfluxData support](https://support.influxdata.com/s/login/)
|
||||
to invite a user to your account.
|
||||
In your request, provide the user details, including email address, desired
|
||||
[user groups](#available-user-groups), and other attributes for the user.
|
||||
2. InfluxData support creates the user account and emails the user an invitation
|
||||
that includes following:
|
||||
|
||||
- An **Auth0 login** to authenticate access to the cluster
|
||||
- The {{% product-name %}} **account ID**
|
||||
- The {{% product-name %}} **cluster ID**
|
||||
- The {{% product-name %}} **cluster URL**
|
||||
- A password reset email for setting the login password
|
||||
|
||||
3. The user accepts the invitation to your account
|
||||
|
||||
With a valid password, the user can access cluster resources by interacting with the
|
||||
[`influxctl`](/influxdb/cloud-dedicated/reference/influxctl/) command line tool.
|
||||
The assigned user groups determine the user's access to resources.
|
||||
|
||||
{{% note %}}
|
||||
#### Use database tokens to authorize data reads and writes
|
||||
|
||||
In {{% product-name %}}, user groups control access for managing cluster resources.
|
||||
[Database tokens](/influxdb/cloud-dedicated/admin/tokens/database/) control access
|
||||
for reading and writing data in cluster databases.
|
||||
{{% /note %}}
|
||||
|
|
@ -238,13 +238,15 @@ separates workload cluster management authorizations (using _management tokens_)
|
|||
from database read and write authorizations (using _database tokens_).
|
||||
|
||||
- [User provisioning](#user-provisioning)
|
||||
- [User groups](#user-groups)
|
||||
- [Management tokens](#management-tokens)
|
||||
- [Database tokens](#database-tokens)
|
||||
|
||||
#### User provisioning
|
||||
|
||||
InfluxData uses [Auth0](https://auth0.com/) to create user accounts and assign
|
||||
permission sets to user accounts on {{% product-name %}}.
|
||||
InfluxData uses [Auth0](https://auth0.com/) to create user accounts and
|
||||
assign user attributes, including [user groups](#user-groups), on {{% product-name %}}.
|
||||
|
||||
After a user account is created, InfluxData provides the user with the following:
|
||||
|
||||
- An **Auth0 login** to authenticate access to the cluster
|
||||
|
|
@ -260,13 +262,49 @@ exchanged with `influxctl`.
|
|||
After a successful Auth0 authentication, {{% product-name %}} provides the
|
||||
user's `influxctl` session with a short-lived
|
||||
[management token](#management-tokens) for access to the Granite service.
|
||||
The user interacts with the `influxctl` command line tool to manage the workload
|
||||
cluster, including creating [database tokens](#database-tokens) for database
|
||||
read and write access and [creating long-lived management tokens](/influxdb/cloud-dedicated/admin/management-tokens/)
|
||||
for use with the [Management API](/influxdb/cloud-dedicated/api/management/).
|
||||
The user interacts with the `influxctl` command line tool to view or manage
|
||||
cluster resources.
|
||||
The [user groups](#user-groups) assigned to the user determine the level of
|
||||
access to resources.
|
||||
|
||||
#### User groups
|
||||
|
||||
User groups associate access privileges with user attributes--an important part of the
|
||||
Attribute-Based Access Control (ABAC) security model, which grants access based on
|
||||
user attributes, resource types, and environment context.
|
||||
|
||||
In {{% product-name %}}, a user can belong to any of the following user groups,
|
||||
each with predefined privileges:
|
||||
|
||||
- [Admin user group]
|
||||
- [Member user group]
|
||||
- [Auditor user group]
|
||||
|
||||
##### Admin user group
|
||||
|
||||
Admins are {{% product-name %}} users who have read and write permissions on
|
||||
all resources (for all clusters) in the account.
|
||||
Only Admins can create [management tokens](#management-tokens).
|
||||
|
||||
##### Members (role: member)
|
||||
|
||||
<!-- Define "certain resources" below: -->
|
||||
|
||||
Members are {{% product-name %}} users who have read permission on certain
|
||||
resources and create permission for [database tokens](#database-tokens).
|
||||
Members can't delete or create databases or management tokens.
|
||||
|
||||
##### Auditor (role: auditor)
|
||||
|
||||
Auditors are {{% product-name %}} users who have read permission on all resources
|
||||
(for all clusters) in the account; auditors can't modify account resources.
|
||||
|
||||
#### Management tokens
|
||||
|
||||
[Admins](#admin-group) can create long-lived
|
||||
[management tokens](/influxdb/cloud-dedicated/admin/management-tokens/)
|
||||
for use with the [Management API](/influxdb/cloud-dedicated/api/management/).
|
||||
|
||||
Management tokens authenticate user accounts to the Granite service and provide
|
||||
authorizations for workload cluster management activities, including:
|
||||
|
||||
|
|
@ -308,6 +346,12 @@ cases--for example, using the [Management API for
|
|||
{{% product-name %}}](/influxdb/cloud-dedicated/api/management/) to rotate
|
||||
database tokens or create tables.
|
||||
|
||||
Manually created management tokens:
|
||||
|
||||
- have an optional expiration and don't require human interaction with the OAuth provider
|
||||
- are for automation use cases
|
||||
- shouldn't be used to circumvent the OAuth provider
|
||||
|
||||
To authenticate a Management API request, the user passes the manually created
|
||||
token in the HTTP `Authorization` header:
|
||||
|
||||
|
|
@ -315,17 +359,15 @@ token in the HTTP `Authorization` header:
|
|||
Authorization MANAGEMENT_TOKEN
|
||||
```
|
||||
|
||||
A manually created management token has an optional expiration and
|
||||
doesn't require human interaction with the OAuth provider.
|
||||
|
||||
Manually created management tokens are meant for automation use cases
|
||||
and shouldn't be used to circumvent the OAuth provider.
|
||||
|
||||
#### Database tokens
|
||||
|
||||
Database tokens provide authorization for users and client applications to read and write data and metadata in an {{% product-name %}} database.
|
||||
[Admins](#admin-group) and [Members](#member-group), can create
|
||||
[database tokens](#database-tokens) for database read and write access.
|
||||
Database tokens provide authorization for users and client applications to read
|
||||
and write data and metadata in an {{% product-name %}} database.
|
||||
All data write and query API requests require a valid database token with sufficient permissions.
|
||||
_**Note:** an all-access management token can't read or write to a database because it's not a database token._
|
||||
_**Note:** an all-access [management token](#management-tokens) can't read or
|
||||
write to a database because it's not a database token._
|
||||
|
||||
Database tokens consist of the following:
|
||||
|
||||
|
|
|
|||
|
|
@ -119,7 +119,12 @@ spec:
|
|||
jwksEndpoint: |-
|
||||
https://AUTH0_HOST/.well-known/openid-configuration
|
||||
users:
|
||||
- AUTH0_USER_ID
|
||||
# All fields are required but `firstName`, `lastName`, and `email` can be
|
||||
# arbitrary values. However, `id` must match the user ID provided by Auth0.
|
||||
- id: AUTH0_USER_ID
|
||||
firstName: Marty
|
||||
lastName: McFly
|
||||
email: mcfly@influxdata.com
|
||||
```
|
||||
|
||||
{{% /code-placeholders %}}
|
||||
|
|
@ -152,7 +157,12 @@ spec:
|
|||
jwksEndpoint: |-
|
||||
https://login.microsoftonline.com/AZURE_TENANT_ID/discovery/v2.0/keys
|
||||
users:
|
||||
- AZURE_USER_ID
|
||||
# All fields are required but `firstName`, `lastName`, and `email` can be
|
||||
# arbitrary values. However, `id` must match the user ID provided by Azure.
|
||||
- id: AZURE_USER_ID
|
||||
firstName: Marty
|
||||
lastName: McFly
|
||||
email: mcfly@influxdata.com
|
||||
```
|
||||
|
||||
{{% /code-placeholders %}}
|
||||
|
|
@ -249,7 +259,12 @@ admin:
|
|||
https://AUTH0_HOST/.well-known/openid-configuration
|
||||
# The list of users to grant access to Clustered via influxctl
|
||||
users:
|
||||
- AUTH0_USER_ID
|
||||
# All fields are required but `firstName`, `lastName`, and `email` can be
|
||||
# arbitrary values. However, `id` must match the user ID provided by Auth0.
|
||||
- id: AUTH0_USER_ID
|
||||
firstName: Marty
|
||||
lastName: McFly
|
||||
email: mcfly@influxdata.com
|
||||
```
|
||||
|
||||
{{% /code-placeholders %}}
|
||||
|
|
@ -280,7 +295,12 @@ admin:
|
|||
https://login.microsoftonline.com/AZURE_TENANT_ID/discovery/v2.0/keys
|
||||
# The list of users to grant access to Clustered via influxctl
|
||||
users:
|
||||
- AZURE_USER_ID
|
||||
# All fields are required but `firstName`, `lastName`, and `email` can be
|
||||
# arbitrary values. However, `id` must match the user ID provided by Azure.
|
||||
- id: AZURE_USER_ID
|
||||
firstName: Marty
|
||||
lastName: McFly
|
||||
email: mcfly@influxdata.com
|
||||
```
|
||||
|
||||
{{% /code-placeholders %}}
|
||||
|
|
|
|||
|
|
@ -683,4 +683,281 @@ Replace the following:
|
|||
|
||||
---
|
||||
|
||||
{{< page-nav prev="/influxdb/clustered/install/secure-cluster/auth/" prevText="Set up authentication" next="/influxdb/clustered/install/set-up-cluster/licensing" nextText="Install your license" tab="Helm" >}}
|
||||
#### Configure your OAuth2 provider
|
||||
|
||||
InfluxDB Clustered uses OAuth2 to authenticate administrative access to your cluster.
|
||||
To connect your InfluxDB cluster to your OAuth2 provide, provide values for the
|
||||
following fields in your `values.yaml`:
|
||||
|
||||
- `admin`
|
||||
- `identityProvider`: Identity provider name.
|
||||
_If using Microsoft Entra ID (formerly Azure Active Directory), set the name
|
||||
to `azure`_.
|
||||
- `jwksEndpoint`: JWKS endpoint provide by your identity provider.
|
||||
- `users`: List of OAuth2 users to grant administrative access to your
|
||||
InfluxDB cluster. IDs are provided by your identity provider.
|
||||
|
||||
Below are examples for **Keycloak**, **Auth0**, and **Microsoft Entra ID**, but
|
||||
other OAuth2 providers should work as well:
|
||||
|
||||
{{< code-tabs-wrapper >}}
|
||||
{{% code-tabs %}}
|
||||
[Keycloak](#)
|
||||
[Auth0](#)
|
||||
[Microsoft Entra ID](#)
|
||||
{{% /code-tabs %}}
|
||||
{{% code-tab-content %}}
|
||||
|
||||
{{% code-callout "keycloak" "green" %}}
|
||||
{{% code-placeholders "KEYCLOAK_(HOST|REALM|USER_ID)" %}}
|
||||
|
||||
```yaml
|
||||
admin:
|
||||
# The identity provider to be used e.g. "keycloak", "auth0", "azure", etc
|
||||
# Note for Azure Active Directory it must be exactly "azure"
|
||||
identityProvider: keycloak
|
||||
# The JWKS endpoint provided by the Identity Provider
|
||||
jwksEndpoint: |-
|
||||
https://KEYCLOAK_HOST/auth/realms/KEYCLOAK_REALM/protocol/openid-connect/certs
|
||||
# The list of users to grant access to Clustered via influxctl
|
||||
users:
|
||||
# All fields are required but `firstName`, `lastName`, and `email` can be
|
||||
# arbitrary values. However, `id` must match the user ID provided by Keycloak.
|
||||
- id: KEYCLOAK_USER_ID
|
||||
firstName: Marty
|
||||
lastName: McFly
|
||||
email: mcfly@influxdata.com
|
||||
```
|
||||
|
||||
{{% /code-placeholders %}}
|
||||
{{% /code-callout %}}
|
||||
|
||||
---
|
||||
|
||||
Replace the following:
|
||||
|
||||
- {{% code-placeholder-key %}}`KEYCLOAK_HOST`{{% /code-placeholder-key %}}:
|
||||
Host and port of your Keycloak server
|
||||
- {{% code-placeholder-key %}}`KEYCLOAK_REALM`{{% /code-placeholder-key %}}:
|
||||
Keycloak realm
|
||||
- {{% code-placeholder-key %}}`KEYCLOAK_USER_ID`{{% /code-placeholder-key %}}:
|
||||
Keycloak user ID to grant InfluxDB administrative access to
|
||||
|
||||
---
|
||||
|
||||
{{% /code-tab-content %}}
|
||||
{{% code-tab-content %}}
|
||||
|
||||
{{% code-callout "auth0" "green" %}}
|
||||
{{% code-placeholders "AUTH0_(HOST|USER_ID)" %}}
|
||||
|
||||
```yaml
|
||||
admin:
|
||||
# The identity provider to be used e.g. "keycloak", "auth0", "azure", etc
|
||||
# Note for Azure Active Directory it must be exactly "azure"
|
||||
identityProvider: auth0
|
||||
# The JWKS endpoint provided by the Identity Provider
|
||||
jwksEndpoint: |-
|
||||
https://AUTH0_HOST/.well-known/openid-configuration
|
||||
# The list of users to grant access to Clustered via influxctl
|
||||
users:
|
||||
- AUTH0_USER_ID
|
||||
```
|
||||
|
||||
{{% /code-placeholders %}}
|
||||
{{% /code-callout %}}
|
||||
|
||||
---
|
||||
|
||||
Replace the following:
|
||||
|
||||
- {{% code-placeholder-key %}}`AUTH0_HOST`{{% /code-placeholder-key %}}:
|
||||
Host and port of your Auth0 server
|
||||
- {{% code-placeholder-key %}}`AUTH0_USER_ID`{{% /code-placeholder-key %}}:
|
||||
Auth0 user ID to grant InfluxDB administrative access to
|
||||
|
||||
---
|
||||
|
||||
{{% /code-tab-content %}}
|
||||
{{% code-tab-content %}}
|
||||
|
||||
{{% code-callout "azure" "green" %}}
|
||||
{{% code-placeholders "AZURE_(USER|TENANT)_ID" %}}
|
||||
|
||||
```yaml
|
||||
admin:
|
||||
# The identity provider to be used e.g. "keycloak", "auth0", "azure", etc
|
||||
# Note for Azure Active Directory it must be exactly "azure"
|
||||
identityProvider: azure
|
||||
# The JWKS endpoint provided by the Identity Provider
|
||||
jwksEndpoint: |-
|
||||
https://login.microsoftonline.com/AZURE_TENANT_ID/discovery/v2.0/keys
|
||||
# The list of users to grant access to Clustered via influxctl
|
||||
users:
|
||||
- AZURE_USER_ID
|
||||
```
|
||||
|
||||
{{% /code-placeholders %}}
|
||||
{{% /code-callout %}}
|
||||
|
||||
---
|
||||
|
||||
Replace the following:
|
||||
|
||||
- {{% code-placeholder-key %}}`AZURE_TENANT_ID`{{% /code-placeholder-key %}}:
|
||||
Microsoft Entra tenant ID
|
||||
- {{% code-placeholder-key %}}`AZURE_USER_ID`{{% /code-placeholder-key %}}:
|
||||
Microsoft Entra user ID to grant InfluxDB administrative access to
|
||||
_(See [Find user IDs with Microsoft Entra ID](/influxdb/clustered/install/auth/?t=Microsoft+Entra+ID#find-user-ids-with-microsoft-entra-id))_
|
||||
|
||||
---
|
||||
|
||||
{{% /code-tab-content %}}
|
||||
{{< /code-tabs-wrapper >}}
|
||||
|
||||
##### Add users
|
||||
|
||||
Finally, add the users you wish to have access to use `influxctl`.
|
||||
Update the `admin.users` field with a list of the users.
|
||||
See [Manage users](/influxdb/clustered/admin/users/) for more details.
|
||||
|
||||
#### Configure the size of your cluster
|
||||
|
||||
By default, an InfluxDB cluster is configured with the following:
|
||||
|
||||
- **3 ingesters**:
|
||||
Ensures redundancy on the write path.
|
||||
- **1 compactor**:
|
||||
While you can have multiple compactors, it is more efficient to scale the
|
||||
compactor vertically (assign more CPU and memory) rather than horizontally
|
||||
(increase the number of compactors).
|
||||
- **1 querier**:
|
||||
The optimal number of queriers depends on the number of concurrent queries you are
|
||||
likely to have and how long they take to execute.
|
||||
|
||||
The default values provide a good starting point for testing.
|
||||
Once you have your cluster up and running and are looking for scaling recommendations,
|
||||
please [contact the InfluxData Support team](https://support.influxdata.com).
|
||||
We are happy to work with you to identify appropriate scale settings based on
|
||||
your anticipated workload.
|
||||
|
||||
**To use custom scale settings for your InfluxDB cluster**, modify the following fields
|
||||
in your values.yaml`. If omitted, your cluster will use the default scale settings.
|
||||
|
||||
- `resources`
|
||||
- `ingester.requests`
|
||||
- `cpu`: CPU resource units to assign to ingesters
|
||||
- `memory`: Memory resource units to assign to ingesters
|
||||
- `replicas`: Number of ingester replicas to provision
|
||||
- `compactor.requests`
|
||||
- `cpu`: CPU resource units to assign to compactors
|
||||
- `memory`: Memory resource units to assign to compactors
|
||||
- `replicas`: Number of compactor replicas to provision
|
||||
- `querier.requests`
|
||||
- `cpu`: CPU resource units to assign to queriers
|
||||
- `memory`: Memory resource units to assign to queriers
|
||||
- `replicas`: Number of querier replicas to provision
|
||||
- `router.requests`
|
||||
- `cpu`: CPU resource units to assign to routers
|
||||
- `memory`: Memory resource units to assign to routers
|
||||
- `replicas`: Number of router replicas to provision
|
||||
|
||||
###### Related Kubernetes documentation
|
||||
|
||||
- [CPU resource units](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu)
|
||||
- [Memory resource units](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#meaning-of-memory)
|
||||
|
||||
{{% code-placeholders "(INGESTER|COMPACTOR|QUERIER|ROUTER)_(CPU|MEMORY|REPLICAS)" %}}
|
||||
|
||||
```yml
|
||||
# The following settings tune the various pods for their cpu/memory/replicas
|
||||
# based on workload needs. Only uncomment the specific resources you want
|
||||
# to change. Anything left commented will use the package default.
|
||||
resources:
|
||||
# The ingester handles data being written
|
||||
ingester:
|
||||
requests:
|
||||
cpu: INGESTER_CPU
|
||||
memory: INGESTER_MEMORY
|
||||
replicas: INGESTER_REPLICAS # Default is 3
|
||||
|
||||
# The compactor reorganizes old data to improve query and storage efficiency.
|
||||
compactor:
|
||||
requests:
|
||||
cpu: COMPACTOR_CPU
|
||||
memory: COMPACTOR_MEMORY
|
||||
replicas: COMPACTOR_REPLICAS # Default is 1
|
||||
|
||||
# The querier handles querying data.
|
||||
querier:
|
||||
requests:
|
||||
cpu: QUERIER_CPU
|
||||
memory: QUERIER_MEMORY
|
||||
replicas: QUERIER_REPLICAS # Default is 1
|
||||
|
||||
# The router performs some api routing.
|
||||
router:
|
||||
requests:
|
||||
cpu: ROUTER_CPU
|
||||
memory: ROUTER_MEMORY
|
||||
replicas: ROUTER_REPLICAS # Default is 1
|
||||
```
|
||||
|
||||
{{% /code-placeholders %}}
|
||||
|
||||
### Provide a custom certificate authority bundle {note="Optional"}
|
||||
|
||||
InfluxDB attempts to make TLS connections to the services it depends on; notably
|
||||
the [Catalog](/influxdb/clustered/reference/internals/storage-engine/#catalog),
|
||||
and the [Object store](/influxdb/clustered/reference/internals/storage-engine/#object-store).
|
||||
InfluxDB validates the certificates for all of the connections it makes.
|
||||
|
||||
**If you host these services yourself and you use a private or otherwise not
|
||||
well-known certificate authority to issue certificates to theses services**,
|
||||
InfluxDB will not recognize the issuer and will be unable to validate the certificates.
|
||||
To allow InfluxDB to validate these certificates, provide a PEM certificate
|
||||
bundle containing your custom certificate authority chain.
|
||||
|
||||
1. Use `kubectl` to create a config map containing your PEM bundle.
|
||||
Your certificate authority administrator should provide you with a
|
||||
PEM-formatted certificate bundle file.
|
||||
|
||||
{{% note %}}
|
||||
This PEM-formatted bundle file is *not* the certificate that InfluxDB uses to
|
||||
host its own TLS endpoints. This bundle establishes a chain of trust for the
|
||||
external services that InfluxDB depends on.
|
||||
{{% /note %}}
|
||||
|
||||
In the example below, `private_ca.pem` is the certificate bundle file.
|
||||
|
||||
```sh
|
||||
kubectl --namespace influxdb create configmap custom-ca --from-file=certs.pem=/path/to/private_ca.pem
|
||||
```
|
||||
|
||||
{{% note %}}
|
||||
It's possible to append multiple certificates into the same bundle.
|
||||
This can help if you need to include intermediate certificates or explicitly
|
||||
include leaf certificates. Leaf certificates should be included before any
|
||||
intermediate certificates they depend on. The root certificate should
|
||||
be last in the bundle.
|
||||
{{% /note %}}
|
||||
|
||||
2. Update your `values.yaml` to enable custom egress and refer to your
|
||||
certificate authority config map. Set `useCustomEgress` to `true` and update
|
||||
the `egress` property to refer to that config map. For example:
|
||||
|
||||
```yml
|
||||
useCustomEgress: true
|
||||
egress:
|
||||
# # If you're using a custom CA you will need to specify the full custom CA bundle here.
|
||||
# #
|
||||
# # NOTE: the custom CA is currently only honoured for outbound requests used to obtain
|
||||
# # the JWT public keys from your identiy provider (see `jwksEndpoint`).
|
||||
customCertificates:
|
||||
valueFrom:
|
||||
configMapKeyRef:
|
||||
key: ca.pem
|
||||
name: custom-ca
|
||||
```
|
||||
|
||||
{{< page-nav prev="/influxdb/clustered/install/auth/" prevText="Set up authentication" next="/influxdb/clustered/install/licensing" nextText="Install your license" tab="Helm" >}}
|
||||
|
|
|
|||
Loading…
Reference in New Issue