Hi, We have hosted Conjur-OSS in a dedicated kubernates cluster, applications which are running in different clusters wanted to pull the secrets from conjur using k8s-authn, secretless-broker.
applications which are deployed in the same cluster where conjur is deployed are successfully pulling secrets from conjur. but the applications which are deployed in different cluster are getting issue in pulling secrets.
Any help with this issue.
Hi @rgidda,
Currently Conjur’s authn-k8s authenticator only supports authenticating workloads in the same cluster as the Conjur instance. You would need to use another authenticator for cross-cluster authentication.
There has been discussion about removing this limitation in the future but it’s not currently scheduled on our roadmap.
Thanks @szh for the replay,
I think Secretless Broker will also not work since it follows certificate based authentication ?
We have tested authn_jwt for cross cluster authentication and it is working fine, Can you please list the authenticator’s which we can use for cross cluster (if you have list handy).
one more clarification pls, how much safe to use JWT authenticator , any drawbacks ?
@rgidda, excellent questions. I’ll address the two questions (authenticators which support cross-cluster authentication, and JWT vs K8s authenticator security), separately:
Authenticators which support cross-cluster authentication
Authn-K8s and Authn-JWT are the two good options for authenticating workloads in Kubernetes, but there are some caveats/best practices.
All Conjur authenticators work by validating an external identity (usually a Kubernetes Service Account) against a single validation endpoint. For the Authn-K8s authenticator, this endpoint is the Kubernetes API. For Authn-JWT, this is a valid JWKS endpoint.
To use Authn-K8s with multiple clusters, you’ll need to create a unique Authn-K8s authenticator for each cluster in Conjur. The Secretless Broker deployment in each cluster needs to configured to authenticate using that cluster’s K8s authenticator.
We’d recommend you create a single Conjur Group for your target application. This group should have authenticate permission for relevant cluster authenticators. This allows you to grant the application group permission to relevant secrets and authenticators instead of assigning permissions to a specific host.
Please note, if Conjur is running inside only one of a Kubernetes clusters, Conjur will need access to the Kubernetes API of the other clusters which need to authenticate workloads. Providing API access to external cluster services is not something that’s always possible (dependent on the org’s internal networking security best practices). In these case, Conjur can be run in each cluster (for OSS, using an external database), or use Authn-JWT.
If your organization uses a common private key for signing JWT certificates across all clusters, you can use a single JWT authenticator. If each cluster has a unique private key, you’ll need to configure a unique JWT authenticator for each cluster.
JWT vs K8s authenticator security
JWT and K8S offer similar levels of security. Authn-K8s can be clunky to use, but incorperates security best practices as a default. The JWT authenticator is more flexible, but places some of the security responsibility on the end consumer.
It is important the JWT private key is kept secure. If this key becomes available to an attacker, it can be used to mint valid JWTs, which can be used to retrieve secrets. Private signing keys should be periodically regenerated. Issued JWTs should have a limited time to live (token valid for an hour limits the time a stolen JWT can be used). Also, please use strong encryption (SHA-256, ES256, or similar).
Choosing one over the other ultimately comes down your organization’s needs and security maturity level and risk tolerance. Either can be a secure option.
1 Like