# Use the Confluent CLI with multiple credentials on Confluent Cloud You can use the Confluent CLI [confluent kafka topic produce](https://docs.confluent.io/confluent-cli/current/command-reference/kafka/topic/confluent_kafka_topic_produce.html) and [confluent kafka topic consume](https://docs.confluent.io/confluent-cli/current/command-reference/kafka/topic/confluent_kafka_topic_consume.html) commands to set up [API keys](../authenticate/workload-identities/service-accounts/api-keys/overview.md#api-keys-overview) not tied to any user account. This is recommended for a more secure setup, in cases where you are not using [service accounts](../authenticate/workload-identities/service-accounts/manage-service-accounts.md#manage-service-accounts). ## User-agnostic API keys for produce and consume Specify API keys and API secrets directly on producers and consumers. Previous versions of the Confluent CLI offered the option to create your own *custom contexts* for user-agnostic authentication of producers and consumers into Confluent Cloud. (You could pair API keys and API secrets with custom contexts instead of user accounts.) In current versions of the Confluent CLI (v.3 and newer), [confluent kafka topic produce](https://docs.confluent.io/confluent-cli/current/command-reference/kafka/topic/confluent_kafka_topic_produce.html) and [confluent kafka topic consume](https://docs.confluent.io/confluent-cli/current/command-reference/kafka/topic/confluent_kafka_topic_consume.html) support the `--bootstrap`, `--api-key`, and `--api-secret` flags directly so that custom contexts are not unnecessary. Use these `produce` and `consume` commands for user-agnostic authentication into Confluent Cloud. ## Using system-provided contexts You can provide restricted access to Confluent Cloud resources by using the Confluent CLI with system-provided contexts. A context represents a user’s login state, whether that be with Confluent Cloud or Confluent Platform, and other associated settings that persist between command executions. ## Hybrid use cases The ability to quickly switch contexts is especially important to hybrid users using both Confluent Cloud and Confluent Platform. Run `confluent context list` to see the list of available contexts: ```bash confluent context list ``` If a context name is too tedious to type, it can be renamed: ```bash confluent context update --name cloud ``` Then, switching to a new context is as easy as: ```bash confluent context use cloud ``` For a detailed example, see [Context switching](https://www.confluent.io/blog/data-pipelines-are-even-easier-with-confluent-cli-v2/#context-switching) and [Hybrid demo](https://www.confluent.io/blog/data-pipelines-are-even-easier-with-confluent-cli-v2/#hybrid-use-cases) in the CLI blog posts. ## Schema contexts *Contexts* can also be used to group schema subject names and IDs, and provide flexibility for referencing schemas, and are a key component of [Schema Linking](../../sr/schema-linking.md#schema-linking). In these scenarios, you do have the option to create custom *schema contexts*. To learn more, see [Work with schema contexts](../../sr/schemas-manage.md#work-with-schema-contexts). ## Related content - [confluent kafka topic produce](https://docs.confluent.io/confluent-cli/current/command-reference/kafka/topic/confluent_kafka_topic_produce.html) - [confluent kafka topic consume](https://docs.confluent.io/confluent-cli/current/command-reference/kafka/topic/confluent_kafka_topic_consume.html) - [Use API Keys to Authenticate to Confluent Cloud](../authenticate/workload-identities/service-accounts/api-keys/overview.md#cloud-api-keys) - [service accounts](../authenticate/workload-identities/service-accounts/manage-service-accounts.md#manage-service-accounts) - Blog post: [Context switching](https://www.confluent.io/blog/data-pipelines-are-even-easier-with-confluent-cli-v2/#context-switching) with an active cluster.