Conjur is an open source programmatic interface which integrates with popular tools to provide secrets management, data encryption, identity management for non-human identities and hosts, and role-based access control (RBAC) for sensitive secrets like passwords, SSH keys, API Keys, certificates, tokens, etc.
A secret is a private piece of information that acts as a key to unlock protected resources or data. The most common types of secrets (sometimes called credentials) are passwords, certificates, SSH keys, API keys, and similar encryption keys. Anyone who has access to a secret, has access and permission to any resources the owner of that secret has. An attacker can use this access to gain access to additional secrets and hosts and can spread an attack far beyond the scope of the initial breach.
Proper secrets management allows users to control who has access to what and have full confidence that their resources can only be accessed by authenticated and authorized entities. This is usually done by providing authentication of access requests, auditing, tight control of secrets, secrets rotation, and the removal of secrets from code, configuration files, and other unprotected areas.
Security Policy as Code
Teams that use code to specify security policy can maintain DevOps velocity without compromising security.
A fundamental concept of DevOps is “infrastructure as code”, also known as “immutable infrastructure”. Operators declare their infrastructure needs in code, replacing the old model of manually administering and configuring servers and software. “Infrastructure as code” prevents instances of servers that have been manually configured and cannot be recreated in case of failure. More importantly, “Infrastructure as code” enables automatic scaling, and creates predictability as new features roll into different test environments and into production. The code that represents this infrastructure is checked into source control similarly to application code, and can be versioned, compared, and protected.
Machine identity is a critical prerequisite for secure non-human access, no access should be grated without this. A container (non-human identity) requesting secrets must be authenticated against a strong non-human identity before it can be authorized to access secrets. Typically, an authenticator certifies that the client run-time container attributes of the requesting container match the native characteristics of the valid container. Once authenticated, the container can access multiple resources, based on predefined RBAC policies.
Role-Based Access Control (RBAC)
RBAC is the definition of organizational roles such as administrators, supervisors, users with full access, and users with read-only access. Organizational users are assigned a role based on the access they require to do their job. The same concept can be applied on non-human identities and be leveraged to provide access to applications based on predefined RBAC policies.
The RBAC usually assigns access rights to a group and not to a specific user. In the case of non-human identities, a group of hosts (a non-human entity), is called a “layer” and can be assigned access rights the same way groups can. This approach reduces the overhead to manage users or non-humans, eliminates access errors, and facilitates auditing.