Terraform supports adding an additional file with variables during invocation.
We are using that feature to provide a secrets.tfvars file on each invocation of Terraform. We also use a script to wrap the command so that its invocation is consistent, and all team ...
The host on which the containers are running
Run the docker security bench on every node that runs docker containers https://github.com/docker/docker-bench-security
Running the following command on a node that runs docker containers:
docker run -it --net host --pid host --cap-add audit_control \
-e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \
In short, you cannot prevent your customers from modifying containers they run in their own infrastructure. Containers are not like binaries that can be obfuscated; they are runtime environments. The code you distribute inside the container, however, can be obfuscated.
Your question alludes to a third-party support issue: clients modifying software they ...
I'd agree this is a buzzword as much as DevOps can be.
Main task of a SecOps added on top of an usual operational engineer tasks is to take the burden of following CVE publication feeds, handling the remediation, usually handling things historically handled by the security or network administration team (Firewall rules, Web Applications Firewall exceptions)
The idea is to put all our sensitive data [...]
The meaning of "all" in this sentence should be analyzed very carefully before implementing the solution that you plan.
Ansible vault is a very useful tool, but it should be used only to store secrets that are:
Specifically needed for the ansible deployments
Easily made useless to owners that should become ...
If you're on AWS, then have a look at "The Right Way to Manage Secrets" by Segment.io on the AWS Blog. We advocate using chamber to all of our customers for managing secrets. It works by leveraging the AWS Systems Manager Parameter Store (SSM) together with KMS keys. This ensures secrets are encrypted at rest (and in transit), secured with IAM, auditable ...
Docker doesn't provide any means to preclude user access to the container, however as the image developer you could follow a few strategy
Obfuscate your software (ruby, python and etc)
Build your image from a base image that doesn't have shell, and other binaries that the user can use to tramper the image.
Of course they can always export the container ...
I do agree with Tensibai's Answer in that SecOps is as much as a buzz-word as DevOps itself and that SecOps is a stepping stone between a siloed organisation and cohesive organisation.
I have observed the flip side to also be true, that is, if you have an organisation who is operating using a DevOps Model, with DevOps ways of working and following DevOps ...
We avoid terraform handle our secrets. Even if you manage to inject secrets by a var file "secrtes.tfvars" as pointed out above, these secrets will be stored in your terraform (remote-)state.
You can protect remote-state files by using e.g. S3 authorization, or you can gitignore local state files but we decided not to rely on this kind of protection.
We are planning to use ansible vault in our project to prevent leaking passwords or keys in git.
Since you haven't yet implemented anything, you might reconsider this. Using a system like Ansible vault has a number of security downsides:
there is no audit trail of who has accessed it
when an employee leaves, it is easy for them to take the secret store ...
In addition to the points in this thread; the following would be my recommendation:
Get control over Docker PID1 with dumb-init
ref: PID1 and Zombie reaping problem
Do not run docker in production without a container orchestration system
Take your pick from Kubernetes, Mesos, Swarm etc.
Use gosu for user control inside a docker image
Follow the 12 ...
Docker is still in development.
As with every other software in-dev bugs will happen, insecure features might be added, there could be architectural flaws that lead to security breaches. Do not underestimate this! Your system might be completely safe today, but with the patch from next week someone finds a bug, writes an exploit, and suddenly your system is ...
Docker images itself
An additional option is to use Clair.
Clair is an open source project for the static analysis of
vulnerabilities in application containers (currently including appc
In regular intervals, Clair ingests vulnerability metadata from a configured set of sources and stores it in the database.
Clients use the ...
Proper management of an application's secrets has always been a challenge. New challenges came with the adoption of the cloud. There's a great OWASP presentation about the reality and challenges of storing secrets in the cloud.
You might be surprised to hear that storing secrets into the source code is one of the solution (or "architecture") presented. That'...
There are a couple of elements to consider here:
It is valuable to have the capability to maintain configuration with a separate release cadence from the code that is being configured. Doing so encourages rotation of credentials in an automated manner, do it regularly make it painless.
It is entirely reasonable from an "Infrastructure as Code" point of ...
Whether you allow remote sudo or remote access to something that does SUID root you have a pretty similar attack surface. I would keep sudo in the chain because it lets you limit the commands easily and has logging that will be vital if you need to audit things later. sudo also has a much longer history in production. Doing something else will have less ...
Since November 2017, it is now possible to directly interact with servers in a VPC \o/
If your client is ready to invest money then you should go with Docker enterprise edition. In Docker EE you have one tool that is UCP(Universal Control Plane) UCP. By UCP you can create roles and access rights and restrict the user to change/modify containers.
If you want to test UCP than DDC(Docker Data Center) having one month trial license which will help ...
Compared to just adding the user to the docker group the second links solution is not any more secure.
Note how that page still can launch with the --privileged flag, and that it is running unconfined.
This means that the container can access all resources including the hosts disks and hardware. It is security ...
No, it's actually really good security practice to sudo when you need higher level privileges. This is the reason that most distributions prohibit default login and actually force you to sudo su instead of just typing su - they want to encourage you to use sudo for it's security benefits. There are few reasons why:
Auditing. When you sudo, the system keeps ...
I don't see a point.
An external attacker (who has access to the host) can easily find where the files are - he only has to look at the last file system layer and will have them presented right there for him.
An internal attacker (who gains access to the container through a misconfigured part of the app or whatever) will also rather easily find them by ...
This is an area where you will need to talk directly to and potentially help educate your auditors. What you have to remember is they are responsible for ensuring that adequate controls are applied, not specifically that "Production Servers have Endpoint Protection"; Anti-virus and Anti-malware are among some of the most basic controls applied to technology....
You can't add deny rules to GC firewall. The default policy is Deny. You can only add allow rules - allow everything you need and let everything else get rejected.
Since the ports you need to block are allowed by default, you simply need to remove them. Check the name of the default rule:
gcloud compute firewall-rules list [NAME …] [--regexp=REGEXP, -r ...
This quite much goes to what internal policies you have on handling sensitive data.
I'd like to tell you my approach to this and explain what I see as pros and cons. I keep the Ansible Vault password in a file on the control machine and have a environment variable pointing to it:
I have that on my ...
Ideally, you should store secrets as environment variables, and retrieve them from a secrets management system like Hashicorp's Vault or AWS Parameter store.
I saw your questions out of turn, and kinda touched on this in your other question:
Again, there are many perfectly valid options for handling secrets: Chef vault, ...
The best protection for your servers if you don't want to expose their HTTPS to the world would be to isolate them in a VPC.
However, API Gateway can't be configured to directly interact with servers in a VPC/subnet (yet). In order to get around that limitation, you can proxy your traffic from the API Gateway through AWS Lambda to reach the VPC. AWS blog ...
For a purely EC2-based environment, the easiest solution is to use AWS IAM roles and S3 bucket policies. Some formulations of this pattern also include KMS for encryption and DynamoDB instead of S3 for storage but I've not found a hugely compelling reason to use either. Check out https://github.com/poise/citadel, it is specifically aimed at Chef users but ...
I think the solution comes down to a broad spectrum of approaches that ensures data protection:
Data Classification: The most efficient technical strategy is to categorise the data at the point of creation rigorously. At its core, the developers are responsible for ensuring that all logged information is assigned a category. Categorization can, for example,...
I have also asked the AWS Support folks for help too, as Lambda's security was crucial for us [HIPAA compliancy].
This was their response:
Lambda has two options, you can have your lambda functions without a
VPC or you could place your lambda function within a VPC. If you want
to put your lambda function within VPC, then the most important thing