During the past few weeks, I have described what a secrets manager is and I have given an overview of the architecture and system requirements of CyberArk Conjur.
A secrets manager can't do his job if he can't talk to those who need to ask him for secrets, and that's where Conjur's magic comes in!
The "authenticators" are responsible of the authentication process in Conjur and they are specialised to make it in the most secure way depending on the service.
Here is the list of the authenticators currently supported :authn | Defines the Conjur default authenticator. Authentication for both users and hosts is based on an ID and API key. |
authn-oidc | Leverages the identity layer provided by OIDC to allow applications to authenticate with Conjur and retrieve secrets needed for connecting to services such as a database. |
authn-iam | Enables an AWS resource to use its AWS IAM role to authenticate with Conjur. |
Enables an Azure resource to authenticate with Conjur | |
Enables an application to authenticate to Conjur using a JWT from a JWT Provider. | |
Enables a Google Cloud Platform resource to authenticate with Conjur | |
authn-k8s | Authenticates hosts that are Kubernetes resources, such as a Kubernetes namespace, deployment, stateful set, and others. Authentication is certificate-based using a mutual TLS connection. |
authn-ldap | Authenticates users based on an LDAP directory. |
- Kubernetes (locali o cloud)
- API gateway
- Jenkins
- Ansible
- Puppet
- Terraform
- Cloud services
No comments:
Post a Comment