Within a DevSecOps Ci/Cd pipeline one of the best practices is to automatically discover and apply patches to vulnerable software prior to deployment.
Is it possible to check a CVE database, find patches, and then deploy. I want to build this capability into my pipeline.
The environments applicable to the above is AWS and Azure.
Can you provide examples of tools I could use to achieve the above?
• Automatically discover and apply patches to vulnerable open-source software prior to deployment.
A tool like Trivy may be your answer.
Trivy looks at the contents of an image to check which packages it includes, scans for all vulnerabilities, and sends them to AWS Security Hub.
If the scan does not uncover vulnerabilities, the Docker images are pushed to Amazon Elastic Container Registry for deployment.
To use Trivy, you must have Security Hub enabled in the AWS Region where you deploy this solution.
There are many other open-source solutions out there. Trivy is just one of them.
Related
I have started using sentry within my org and loving it so far.
I've been trying to use its performance monitoring tool with custom metrics added.
While I can add custom metrics to the transactions I'm generating in sentry_sdk (for Python), I can't get access to them on the dashboard of our self-hosted installation of sentry.
After a lot of digging, I came across this paragraph here which states that
This feature is only available to organization on our latest plans which include Dynamic Sampling. Customers on legacy plans must move to one of these plans in order to access custom metrics.
From what I gather, I believe their plans in general is to run sentry on their servers. Unless you opt-in to their self-hosted code that can be downloaded from github here.
This is absolutely a bummer because I know my org will not consider moving internal data to third-party servers.
Wondering if someone knows of a solution to this problem. If sentry folks know of (paid) options that enables this feature on self-hosted version or if someone has hacked into their open source code?
I'd also love to hear any out-of-the-box suggestion you folks might have.
I would like to restrict a users permissions, so they can't modify infrastructure without going through a process.
For example, as a requirement, a developer must go through the process of opening a PR, code review, tests pass, before it is merged. They can't push to master until that is complete. Similarly, a user should not be able to terraform apply, despite their AWS account having significant access to access/update/delete resources.
The issue is that running terraform plan is very helpful locally, and saves a lot of time when making changes to the HCL files.
Is there a way to restrict the terraform apply step, while still being able to run terraform plan?
Because Terraform and the associated providers run entirely on the machine where Terraform CLI is installed, those components alone are not able to implement any sort of access controls: a user could, for example, simply modify Terraform CLI or one of the providers to not enforce whatever checks you'd put in place.
Instead, enforcing permissions must be done by some other system. There are two main options for this, and these two options are complementary and could be implemented together as part of a "defense in depth" strategy:
Use the access control mechanisms offered by the remote system you are interacting with. For example, if you are working with Amazon Web Services then you can write IAM policies that only permit read access to the services in question, which should then be sufficient for most plan-time operations.
Unfortunately the details about which permissions are required for each operation in AWS are often not clearly documented, so for AWS at least this approach often involves some trial-and-error. Other systems may have clearer documentation.
Require all Terraform usage to be done remotely via some sort of remote automation, where the automation system can then restrict which users are able to start which actions.
There are various automation products which enable restricting which actions are available to which users. HashiCorp also offers Terraform Cloud, which includes the possibility of running Terraform remotely either in an execution context provided by Terraform Cloud itself or via an agent running on your own infrastructure. You can configure Terraform Cloud to allow applying only through the version control workflow.
I want to create a simple CI/CD GitHub system for academic purposes and better understanding of the system. I want to know how can I check if a repository was updated or how can I call and API every time a commit is done. I thought about using GitHub Actions but I think is better if I could do this configurations in the system instead of going in each repository on GitHub.
GitHub Actions is the best way to get started with CI/CD, in my opinion. It's well integrated with GitHub, which most people are already familiar with, and it's plethora of tools are well documented in easy-to-follow tutorials on the GitHub website. If you don't have a very good reason not to use GitHub Actions, and are trying to learn, I would suggest you reconsider.
If you are hellbent on not using GitHub actions, where are you deploying the application? If Azure, use Azure's pipelines (it's the exact same syntax as github actions, btw.); if using AWS or GCP, use the respective CI/CD pipeline UIs offered by those platforms. If you're hosting/deploying on your own machine using something like GitLab, its syntax is very similar to GitHub Actions anyway, and GitLab has good documentation and tutorials as well.
So basically, your options are to use GitHub Actions, which is easy to pick up and highly recommended, or use the pipeline of whichever service you're using to deploy your application.
Say I have a front end node and three backed nodes tools, blog, and store. Each node communicates with the other. Each of these nodes have their own set of languages and libraries, and have their own Dockerfile.
I understand the DevOps lifecycle of a single monolithic web application, but cannot workout how a DevOps pipeline would work for microservices.
Would each micro-service get its own github repo and CI/CD pipeline?
How do I keep the versions in sync? Let's say the tools microservice uses blog version 2.3. But blog just got pushed to version 2.4, which is incompatible with tools. How do I keep the staging and production environments in sync onto which version they are supposed to rely on?
If I'm deploying the service tools to multiple different servers, whose IP's may change, how do the other services find the nearest location of this service?
For a monolithic application, I can run one command and simply navigate to a site to interact with my code. What are good practices for developing locally with several different services?
Where can I go to learn more?
Would each micro-service get its own github repo and CI/CD pipeline?
From my experience you can do both. I saw some teams putting multiple micro-services in one Repository.
We where putting each micro-service in a separate repository as the Jenkins pipeline was build in a generic
way to build them that way. This included having some configuration files in specific directories like
"/Scripts/microserviceConf.json"
This was helping us in some cases. In general you should also consider the Cost as GitHub has a pricing model
which does take into account how many private repositories you have.
How do I keep the versions in sync? Let's say the tools micro-service uses blog version 2.3. But blog just got pushed to version 2.4, which
is incompatible with tools. How do I keep the staging and production
environments in sync onto which version they are supposed to rely on?
You need to be backwards compatible. Means if your blogs 2.4 version is not compatible with tools version 2.3 you will have high dependency
and coupling which is going again one of the key benefits of micro-services. There are many ways how you get around this.
You can introduce a versioning system to your micro-services. If you have a braking change to lets say an api you need to support
the old version for some time still and create a new v2 of the new api. Like POST "blogs/api/blog" would then have a new api
POST "blogs/api/v2/blog" which would have the new features and tools micro-service will have some brige time in which you support
bot api's so it can migrate to v2.
Also take a look at Semantic versioning here.
If I'm deploying the service tools to multiple different servers, whose IP's may change, how do the other services find the nearest
location of this service?
I am not quite sure what you mean here. But this goes in the direction of micro-service orchestration. Usually your Cloud provider specific
service has tools to deal with this. You can take a look at AWS ECS and/or AWS EKS Kubernetes service and how they do it.
For a monolithic application, I can run one command and simply navigate to a site to interact with my code. What are good practices
for developing locally with several different services?
I would suggest to use docker and docker-compose to create your development setup. You would create a local development network of docker
containers which would represent your whole system. This would include: your micro-services, infrastructure(database, cache, helpers) and others. You can read about it more in this answer here. It is described in the section "Considering the Development Setup".
Where can I go to learn more?
There are multiple sources for learning this. Some are:
https://microservices.io/
https://www.datamation.com/applications/devops-and-microservices.html
https://www.mindtree.com/blog/look-devops-microservices
https://learn.microsoft.com/en-us/dotnet/standard/microservices-architecture/multi-container-microservice-net-applications/multi-container-applications-docker-compose
My company has decided to transition to a micro/service based architecture.
We have been doing a bunch of research for the last couple of months on exactly what the architecture of this thing is going to look like.
So far, we've settled on:
Dotnet core for service development (although being language agnostic is somewhat of an end goal)
Kafka for message brokering
Docker
Kubernetes
Ansible
We have a pretty basic proof of concept working, which seems to have ticked all the right boxes with the management team, and is an absolute joy to work with.
My next task is to investigate options for how the development workflow is actually going to work. They are already used to working in a CI/CD manner, with some of their newer products using Jenkins/Octopus Deploy.
My question is: Do any of you have any firm recommendations for setting up a CI/CD pipeline when deploying to a Kubernetes cluster?
A list of must haves is:
Multiple environments i.e. Integration, Test, UAT, Staging, Production.
A means through which different business units can uniquely handle deployments to different environments (development can only push to integration, tester into test, etc). This one is probably their biggest ask - they are used to working with Octopus, and they love the way it handles this.
The ability to roll back / deploy at the click of a button (or with as few steps as possible).
We would be deploying to our own servers initially.
I've spent the past couple of days looking in to options, of which there are many.
So far, Jenkins Pipeline seems like it could be a great start. Spinnakar also seems like a solid choice. I did read a bit into Fabric8, and while it offers much of what I'm asking, it seems a bit like overkill.
If you want to use Jenkins, Pipelines are indeed the way to go. Our setup does pretty much what you want, so let me explain how we set it up.
We use a Jenkins agent that has docker and kubectl installed. This agent first builds the docker container and pushes it to our docker registry. It will then call kubectl in various stages to deploy to our testing, acceptance and production clusters.
Different business units: in a Pipeline you can use an input step to ask whether the Pipeline should proceed or not. You can specify who may press the button, so this is how you could solve the deployment to different clusters. (Ideally, when you get to CD, people will realize that pressing the button several times per day is silly and they'll just automate the entire deployment.)
Rollback: we rely on Kubernetes's rollback system for this.
Credentials: we provision the different Kubernetes credentials using Ansible directly to this Jenkins agent.
To reduce code duplication, we introduced a shared Jenkins Pipeline library, so each (micro)service talks to all Kubernetes clusters in a standardized way.
Note that we use plain Jenkins, Docker and Kubernetes. There is likely tons of software to further ease this process, so let's leave that open for other answers.
We're working on an open source project called Jenkins X which is a proposed sub project of the Jenkins foundation aimed at automating CI/CD on Kubernetes using Jenkins pipelines and GitOps for promotion across environments.
If you want to see how to automate CI/CD with multiple environments on Kubernetes using GitOps for promotion between environments and Preview Environments on Pull Requests you might wanna check out my recent talk on Jenkins X at DevOxx UK where I do a live demo of this on GKE.