Skip to content

Conversation

@anshupande
Copy link
Contributor

No description provided.

@bryanlatten
Copy link

Looks solid, but the twist lock url should be parameterized

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

split out separate sections of this command using \ to make it readable (multiline)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

still needs adobe twistlock URL parameterized (this is a public repo!)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bryanlatten this is temporary URL given by twistlock but yes I will parameterize it

@anshupande
Copy link
Contributor Author

we have now two scripts 1.) twistlock.sh that installs defender on each host 2.) twistlockclientcert.sh that installs client certs for each user and hence each user can get access control to whatever we allow them. Only dependency here is that each unix user should also be a twistlock console user and his username/password should be present in S3

@anshupande
Copy link
Contributor Author

Also @nBerg , I checked following questions with twistlock -
1.) will users be able to reset the env variables to remove twistlock from proxy 2.) Will docker APIs also be inaccessible after we use twistlock access control. 3.) Stability of new setup

and below in response from them-

  1. if a user is root, they can always tamper with any security product on a given host; one of the key reasons to use Twistlock, though, is that your operators no longer need to have root to manage Docker… instead, they can be a regular, non-priviledged user and Twistlock will elevate on their behalf based on the rules you’ve defined… when deployed in this way, users have no choice but to go through Twistlock to manage Docker
  2. the Docker daemon and it’s API endpoints will always be available to you, even with Twistlock in place; you simply need to have your automation tools connect directly to the daemon (as root or a member of the docker group), and they will be able to interact with the API exactly as they do today
  3. I know it’s taken some time to get all the automation worked out, but I’m really confident in the stability of the product… we’re protecting 1000s of customer containers and have only had 2 bugs that involved a crash of our containers or a disruption to a customer host and both were discovered and fixed early in our beta

@anshupande
Copy link
Contributor Author

Duplicate of #139

@anshupande anshupande closed this Mar 1, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants