Opa: Interesting Integrations

[tsandall]

This is a list of potential integrations with other projects.

CI/CD

• Spinnaker is a popular continuous delivery tool. OPA could be integrated with Spinnaker to enforce admission/deployment policies in pipelines. Similar integration could be built for Jenkins. For example: https://blog.armory.io/deployment-policies-with-spinnaker/.

• GitHub actions. @lucperkins has written about integrating OPA with GitHub actions and enforcing policies in CI pipelines.

SDKs

• NodeJS client library to query OPA for policy decisions.

• Heroku buildpack for deploying OPA next to applications.

API Gateways & Platforms

• Apigee is a popular API management platform.

• Ambassador API Gateway is an API gateway built on Envoy. via Daniel Bryant

• AWS Lambda.

Data sources

• Grafaes is an artifact metadata store that could be used to inform policy decisions in various use cases including Kubernetes admission control.

[nrshrivatsan]

Jenkinsfile based pipelines to perform quality gate assertions for policies could be a game changer!

[nrshrivatsan]

The deeper/inner notion really is Permission driven & CONTINUOUSLY GOVERNED PDLC for _Cloud native applications_

[EliuX]

An integration with Travis CI would be great. I imagine some easy code to add to your .travis.yml like

services:
  - opa

[rtrive]

Can i suggest an integration with VerneMQ or Mosquitto?

[tsandall]

@futurama92 sure! Can you provide a brief write up? E.g., provide 2-3 example policies you'd like to have enforced and if you're familiar with those projects how you think the integration might be implemented.

[jamengual]

Jenkins Policy base Slave Election

An Integrations with Jenkins will be great and it has been mention and there are many places where OPA can be integrated with Jenkins at the job execution level that will be very useful.

Another level of integration that is often overlooked and which makes CICD/Security teams mad is the Jenkins Slave selection, which in Jenkins is very simplistic and has no guide rails of any kind.

The problem: Slaves in Jenkins are selected by labels, in one Jenkins master all slaves are available to any user/Job no matter what folder restrictions the user have so there is no way to secure the selection of the Slave base on user:jobid:folderpath or a combination of those.

Imagine this scenario: Jenkins master is deployed in the CICD aws account and Jenkins slaves are distributed in every team's AWS account. If a user from TeamA learns the Label used for TeamB slave the user can change the Jenkins job to use TeamB's slave and run a job that could potentially cause problems, imagine if the pipeline runs terraform import then destroy or some other harmful script.

The proposed solution: An integration with Distributed Builds plugin(ideal) or an Integration of a Proxy/envoy sidecar or other that can intersect the call for the execution of a job in a slave and then run policy against the request arguments and allow/deny the request going to the slave and fail the build.