Get JWT token without public and private keys?

[hongbo-miao]

Hi team, I am wondering if all our pods are exposed by Ingress using https internally, or another case if all pods communication are secured by service mesh with mTLS.

Does it make sense or still secured to provide a flag (or some better ways) to allow us skipping those two flags OPAL_AUTH_PRIVATE_KEY and OPAL_AUTH_PUBLIC_KEY?
Because I found I have to set OPAL_AUTH_PRIVATE_KEY and OPAL_AUTH_PUBLIC_KEY to be able to get JWT token.
Or it will show

opal server was not configured with security, cannot generate tokens!

Simply providing OPAL_AUTH_MASTER_TOKEN is not enough.
Also, CLIENT_SELF_SIGNED_CERTIFICATES_ALLOWED and CLIENT_SSL_CONTEXT_TRUSTED_CA_FILE won't help in this case.

[orweis]

Hi Hongbo :)

Encryption (e.g. TLS or HTTPS) don't save the same problem as the auth tokens (they can only authenticate the server via certificates, not the clients)

The tokens are used to authenticate and authorize(via token types) who's allowed to make changes through OPAL (it's the authorization of the authorization 😅).
You don't want some unrelated service in your system (that was taken over by an attacker for example) to be able to talk to OPAL and change permissions.

That said, if you provide authentication in another way e.g. (API gateway, VPN, ssh tunnel, zerotrust network) it might be okay...

The fear here is that users that don't fully understand the security model will turn this off by mistake without taking the right measures.

Perhaps we can create the flag with a name that makes it clear it's risky to use, e.g.
OPAL_DANGEROUS_NO_AUTH_TOKENS_MODE

@asafc what do you think?

[hongbo-miao]

Thanks @orweis for the info! If that is the case, I will defiantly set up the public and private key!

Just an extra question. Here is an example, as we usually build server that has JWT support for front end app. For this server, I actually never provide extra public and secret key. (Maybe I should but I didn't?)
For higher level, we are using https with CA provided by, for example, Cloudflare.
I am wondering any difference between this example with opal? Thanks!

[orweis]

Usually for WebApps you build you use an authentication solution (e.g. Auth0, AWS-Cognito, KeyCloack) to have users authenticate into the app, and then you use some authorization logic (e.g. OPA, custom code) to decide what each user can do...

The AuthN, or the AuthZ solution take on the responsibility of gating the access.

The same can work here of course, but there's a recursive challenge here you can clearly see- administration for the OPA for OPAL for OPA... 😂

To keep it simple we have OPAL do it's own limited AuthN, and AuthZ - we may change that in the future as OPAL gains more capabilities.

It's a bit confusing, let me know if my answer wasn't clear enough.

[asafc]

@orweis @hongbo-miao regarding the suggested OPAL_DANGEROUS_NO_AUTH_TOKENS_MODE, this is already supported.
Read on, i explained below under "Can I Switch the JWTSigner off?".

I think this is a good opportunity for me to document and explain about the JWTSigner.

What these encryption keys are for?

The encryption keys provided by OPAL_AUTH_PRIVATE_KEY and OPAL_AUTH_PUBLIC_KEY are used by the JWTSigner. They have absolutely nothing to do with SSL/TLS/HTTPs.

• The private key is used to sign on OPAL JWT tokens. it is known only to the OPAL server.
• The public key can be known by anyone, and is used to verify that a specific OPAL server signed on a token without actually knowing the private key.
• You can read more about the principles of Public Key Cryptography here.

What is the JWT Signer?

JWTSigner is a (very) simple AuthN/AuthZ mechanism used between OPAL server and its connected peers (OPAL client, microservices pushing updaters, etc). We use the signed JWT and its claims to make sure that an entity pushing updates or an entity pulling policy and data is actually allowed to do so. We could have used other methods but we wanted something simple for now.

Why do we need AuthN or AuthZ for OPAL?

Since OPAL is trusted to manipulate OPA - OPAL is a very sensitive microservice in your network. OPA is responsible for authorization data and policies - if OPA/OPAL are compromised, so is your app. That is why OPAL must verify that sensitive actions (pushing updates, receiving updates to policy or data) are done only by a trusted and verified entity.

Can i switch the JWT signer off?

Yes, you can already do this from the very first version of OPAL. However, this is not recommended in production environment.

If you do not set both env vars OPAL_AUTH_PRIVATE_KEY and OPAL_AUTH_PUBLIC_KEY, JWTSigner will be disabled. OPAL server will then trust any incoming request without verification.

Maybe we can change the environment variables names - they are indeed confusing.