Vault as an OIDC provider without expose Vault address

I think about configuring Vault as an OIDC provider for my custom C# applications on Kubernetes but I have some concerns before try.

My applications are open to public on internet. They work on Kubernetes (EKS). My EKS has public and private ingresses; something like that:


Let’s suppose that I’ve configured Azure Active Directory with OIDC Auth Method and External Groups as described [here].

I don’t want to expose Vault address to public internet but my custom applications work as internet applications with public access; something like that:

In such a fiction;

Is it possible to configure my custom application to use the private access address of Vault as an OIDC provider on Kubernetes?

Is it possible to use existing AzureAD groups or create new user groups for client app access on Vault without touch AzureAD?

Is it possible to configure 3’rd party applications like Grafana to use Vaults as an standard OIDC provider? If yes, is it possible to use existing AzureAD groups or create new user groups for 3’rd party client app access on Vault without touch AzureAD?

Thanks & Regards

You want to use Vault as an OIDC Identity provider? Considering that involves serving web pages to users’ web browsers, that’s fundamentally in conflict with not exposing it on a public address.

Hell @maxb I think I was misunderstood.
myapp is open to public something like that

…but Vault won’t be open to public; it / its address resided on a private network, something like that

My app shouldn’t use the private address of Vault which is My app needs to use K8s svc account to access vault.vaultnamespace.svc. Of course vault.vaultnamespace.svc is not exposed to public.

Thanks & Regards


Because of security regulations we have, the admin panels mustn’t be accessible from public internet. Our applications are public internet applications. I would like to use Vault as an OIDC provider and set AzureAD as IDP provider. The question is that will my custom application use the ingress address or svc address of Vault to talk with Vault? Because I have to disable the ingress of Vault or use a private subnet load balancer for ingress. I cannot use ingress address of Vault.

Regarding to Concern-3)

OAuth2-proxy is being used for proxy 3’rd party applications to access OAuth providers like AzureAD or Keycloak. AzureAD, Github or Keycloak is sonfigured as standard OAuth2 provider for OAuth-proxy. By same way, Can I configıre Vault as a standard OAuth provider at OAuth2-proxy? Can I use OAuth2-Proxy to proxy 3’rd partym applications’ auth requests?

If OAuth2-Proxy is out of scope of Vault, Does Vault provide an alternative solution for proxying 3’rd applications’ auth requests?

Thanks & Regards

You have said you want to use Vault as an OIDC Identity Provider for various custom applications.

You have not identified which OIDC flow you are seeking to use, so I am assuming you are intending to use the standard Authorization Code flow in the way one usually would for soliciting user authentication in a web browser. This assumption is further supported by references to oauth2-proxy.

I have pointed out that you have impossibly conflicting requirements, since this means your end user web browsers need to be able to reach Vault!!!.

You haven’t really addressed this and have just gone on to say stuff about other parts of the architecture.

Why do you even want to use Vault, if you already have AzureAD as an identity provider anyway?

You say conflicting requirements, it’s ok, it is what it is; just wanted to clarify things in my mind. Because apps contact with Vault through svc address of Vault to access K=V secrets, not through ingress address. I see things work differently when we’re talking about OIDC. It’s make sense.

Existence of a middleware between app and AzureAD is not based on a rational cause (not my recommendation).