do our applications really need to have access to secrets, exposing them as yet another threat vector for credential theft and loss?
i'm an engineer on the cyberark/conjur team. we'd love feedback on our new project, secretless. it is free (as in free, not as in beer) OSS and we think it will help solve some of your thornier security problems. this is not just another secrets vault.
I hereby claim:
To claim this, I am signing this object:
| host_token={{ref('HostFactoryToken')}} | |
| node_name={{ref('NodeName')}} | |
| host_id=$node_name-$(curl http://169.254.169.254/latest/meta-data/instance-id) | |
| host_identity=/var/conjur/host-identity.json | |
| CONJUR_HOST_IDENTITY_VERSION=v1.0.1 | |
| CONJUR_SSH_VERSION=v1.2.5 | |
| export HOME=/root |
| echo "Connecting with Jenkins Swarm plugin" | |
| sudo -H -u jenkins bash -c ' | |
| curl -kL -o $HOME/swarm-client.jar \ | |
| http://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/swarm-client/2.0/swarm-client-2.0-jar-with-dependencies.jar | |
| ' | |
| sudo -H -u jenkins bash -c " | |
| java -jar \$HOME/swarm-client.jar \ | |
| -fsroot /var/lib/jenkins \ | |
| -executors 6 \ |
| diff --git a/config/application.rb b/config/application.rb | |
| index 8682244..d233004 100644 | |
| --- a/config/application.rb | |
| +++ b/config/application.rb | |
| @@ -13,10 +13,11 @@ module ConjurCore | |
| class Application < Rails::Application | |
| config.eager_load_paths << "#{config.root}/app/models/secret_store.rb" | |
| config.encoding = "utf-8" | |
| - config.filter_parameters += [:password] | |
| + config.filter_parameters += [:password, :value] |
Information security practice has evolved to be pretty good at granting and managing access to confidential information - by people. But automation is taking over. Applications, servers, even networks are not configured and deployed by hand anymore. This is great; our systems and delivery pipelines are becoming faster and more robust. Automation, however, requires a shift in how we think about securing our infrastructure and the applications that run on it. When delegating our authority to non-human actors, we want to make sure they can only do what we ask. Modern infrastructure is made of cattle, not pets. A VM or container may be running less than the time it takes to record their existence by hand. In this article, I will cover a few common steps in the modern development lifecycle and share best practices for securing them.
We have just released Conjur CLI v4.28.0!
The big change is that you can now retire policies. Read more about policies here.
These bugs were also fixed:
We have also removed support for per-project .conjurrc files.
| #side-panel { | |
| width: 0; | |
| } | |
| #main-panel { | |
| margin: 0; | |
| } |
A Conjur authenticator which calls out to an external LDAP service to bind.
| # List of created variables | |
| dev_variables = [...] | |
| # Creating a role of type 'variable_group' with name 'dev-variables' | |
| dev_variables_group = role 'variable_group', 'dev-variables' | |
| # Allow that role to execute the variables | |
| dev_variables.each do |v| | |
| v.permit 'execute', dev_variables_group | |
| end |