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 \
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 ...
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 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.
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 ...
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 ...
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 ...
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 ...
Since November 2017, it is now possible to directly interact with servers in a VPC \o/
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 ...
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 ...
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 ...
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 ...
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 ...
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'...
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 ...
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
You can also consider to encrypt the file containing your private SSH key using Ansible Vault.
If your git repos is a private github, you can use github methods (deploy keys is very powerful).
If your repos are not hosted on github or they don't provide read-only deploy key feature, The two options you mentioned are both valuable.
Single DevOps guy
If you are the only person working on the project and Your machine/machines are the only you will run ...
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 ...
The API for creating a function includes a section to choose which VPC to use for running that function.
It doesn't have to be the default VPC, it can be any VPC.
Consider that "EC2 server inside a VPC" only means that it is some virtual ...