#Authentication

1 messages · Page 1 of 1 (latest)

onyx fernBOT
#

Hey there! This channel allows you to ask Kapa.ai for assistance. But it looks like you haven't connected your Discord profile to your Deepgram account yet. You can do so at https://community.deepgram.com - by doing so, you'll be able to ask questions in #1115960287183511643 if you need human assistance!

tame baneBOT
#

Hi @frigid cradle. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:

#

Deepgram’s documentation on self-hosted ingress authentication emphasizes the importance of securing your deployment, especially when exposing services to the public internet. However, it also notes that authentication may be desirable for internal deployments, though it does not provide an exhaustive list of specific internal use cases or conditions.

From the available documentation, the general guidance is that implementing authentication—even for internal deployments—can improve your security posture. This is particularly relevant if:

  • You have multiple internal teams or services accessing the Deepgram instance and want to control or audit access.
  • Your internal network is not fully trusted, or you have concerns about lateral movement within your infrastructure.
  • You need to comply with organizational security policies or regulatory requirements that mandate authentication for all service endpoints, regardless of network exposure.
  • You want to monitor and track API usage internally for operational or billing purposes.

The documentation recommends choosing an authentication method that fits your infrastructure and security requirements, and highlights that “your security posture will be improved by designing your architecture to only access your Deepgram self-hosted services from within your private network, instead of from the public internet”Ingress Authentication Best Practices.

#

In summary, while the documentation does not specify exact internal scenarios, it suggests that any situation where you want to control, monitor, or restrict access—even within a private network—can benefit from ingress authentication for your self-hosted Deepgram deployment. For more detailed or organization-specific recommendations, consulting your IT or security team is advised.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@frigid cradle Kapa.ai is still learning and improving, please let me know how I did by reacting below.

#

Let me check the knowledge base for you again. One moment! :books:

#

Yes, data classification is highly relevant when determining whether ingress authentication is appropriate for your self-hosted Deepgram deployment. While the documentation does not explicitly mention "data classification," it repeatedly emphasizes that self-hosting is often chosen to meet stringent security and data privacy requirements, especially when handling sensitive or regulated data such as personally identifiable information (PII), personal health information (PHI), or payment card information (PCI) Self-hosted Benefits Self-Hosted Introduction.

If the data processed by your Deepgram instance is classified as sensitive, confidential, or subject to regulatory controls, implementing ingress authentication—even within a private network—would be considered a best practice. This helps ensure that only authorized users and systems can access the service, reducing the risk of unauthorized access or data leakage.

The documentation also notes that authentication is crucial for securing your self-hosted instance and that you should "choose a method that best fits your infrastructure and security requirements" Ingress Authentication Best Practices. Security requirements are typically driven by the classification and sensitivity of the data being handled.

In summary, if your data is sensitive or regulated, ingress authentication is strongly recommended, regardless of whether the deployment is public or internal.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@frigid cradle Kapa.ai is still learning and improving, please let me know how I did by reacting below.

#

Let me check the knowledge base for you again. One moment! :books:

#

Yes, even if data is only processed temporarily (e.g., transcribed in memory and not stored persistently), data classification and sensitivity remain important factors in determining whether ingress authentication is appropriate.

Deepgram’s documentation for self-hosted deployments states that, by default, no audio, transcripts, or identifying request content are sent outside your environment, and that request and response data are not stored beyond the duration of the original API request Self-Hosted Introduction. However, it also emphasizes that self-hosting is often chosen to meet strict security and data privacy requirements, especially for sensitive or regulated data.

The documentation recommends implementing authentication as a best practice to secure your self-hosted instance, regardless of whether the data is stored persistently or only processed in memory. This is particularly relevant if the data being processed is sensitive, as unauthorized access—even to transient data—could still pose a risk Ingress Authentication Best Practices.

In summary, the temporary nature of data processing does not eliminate the need for ingress authentication if the data is sensitive or regulated. The decision should be based on the classification and sensitivity of the data, not just on whether it is stored persistently.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: