mirror of
https://github.com/open-policy-agent/opa.git
synced 2026-08-12 19:32:48 -06:00
[docs] Update integrations, organisations and softwares to have pages (#6158)
This PR makes it possible to browse integrations, organizations and related softwares. Previously, these details were only available as modals on the ecosystem page. There are also some changes to the policy enforcement on the docs content, the validation rules are much the same but have been updated to reflect that the content is stored in a new place. I have used some generated JSON in Hugo rather than using GitHub api requests to validate the files since it's A) faster, B) I think more simple, and C) easier to get Hugo to process the markdown frontmatter. Much of the hackery in this PR (Hugo function partials to look up sets of files and get the data from them) is due to the fact that we can't use Hugo's native sections feature. All of our content is nested under docs, this means that all our pages are in the same section so custom lookups have been implemented as function partials instead to work around this. Signed-off-by: Charlie Egan <charlie@styra.com>
This commit is contained in:
Charlie Egan
@@ -311,11 +311,12 @@ jobs:
|
||||
- name: Ensure proper formatting
|
||||
run: opa fmt --list --fail build/policy
|
||||
|
||||
- name: Run policy checks on changed files
|
||||
- name: Run file policy checks on changed files
|
||||
run: |
|
||||
curl --silent --fail --header 'Authorization: Bearer ${{ secrets.GITHUB_TOKEN }}' -o files.json \
|
||||
https://api.github.com/repos/${{ github.repository }}/pulls/${{ github.event.pull_request.number }}/files
|
||||
opa eval --bundle build/policy/ --format values --input files.json \
|
||||
|
||||
opa eval -d build/policy/files.rego -d build/policy/helpers.rego --format values --input files.json \
|
||||
--fail-defined 'data.files.deny[message]'
|
||||
env:
|
||||
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
@@ -323,3 +324,17 @@ jobs:
|
||||
- name: Show input on failure
|
||||
run: opa eval --input files.json --format pretty input
|
||||
if: ${{ failure() }}
|
||||
|
||||
- name: Setup Hugo
|
||||
uses: peaceiris/actions-hugo@v2
|
||||
with:
|
||||
# keep this version in sync with the version in netlify.toml
|
||||
hugo-version: '0.113.0'
|
||||
extended: true
|
||||
|
||||
- name: Build docs site and test integrations data
|
||||
run: |
|
||||
cd docs
|
||||
make dev-generate hugo-production-build
|
||||
cd -
|
||||
opa eval 'data.integrations.deny[message]' -i docs/website/public/index.json -d build/policy/integrations.rego --format=values --fail-defined
|
||||
|
||||
+1
-68
@@ -2,7 +2,7 @@
|
||||
# https://api.github.com/repos/open-policy-agent/opa/pulls/${PR_ID}/files
|
||||
#
|
||||
# Note that the "filename" here refers to the full path of the file, like
|
||||
# docs/website/data/integrations.yaml - since that's how it's named in the
|
||||
# docs/foo/bar.yaml - since that's how it's named in the
|
||||
# input we'll use the same convention here.
|
||||
|
||||
package files
|
||||
@@ -17,8 +17,6 @@ import data.helpers.extension
|
||||
|
||||
filenames := {f.filename | some f in input}
|
||||
|
||||
logo_exts := {"png", "svg"}
|
||||
|
||||
changes[filename] := attributes if {
|
||||
some change in input
|
||||
filename := change.filename
|
||||
@@ -45,69 +43,6 @@ get_file_in_pr(filename) := dump_response_on_error(http.send({
|
||||
"raise_error": false,
|
||||
})).raw_body
|
||||
|
||||
deny contains "Logo must be placed in docs/website/static/img/logos/integrations" if {
|
||||
"docs/website/data/integrations.yaml" in filenames
|
||||
|
||||
some filename in filenames
|
||||
extension(filename) in logo_exts
|
||||
changes[filename].status == "added"
|
||||
directory(filename) != "docs/website/static/img/logos/integrations"
|
||||
}
|
||||
|
||||
deny contains "Logo must be a .png or .svg file" if {
|
||||
"docs/website/data/integrations.yaml" in filenames
|
||||
|
||||
some filename in filenames
|
||||
changes[filename].status == "added"
|
||||
directory(filename) == "docs/website/static/img/logos/integrations"
|
||||
not extension(filename) in logo_exts
|
||||
}
|
||||
|
||||
deny contains "Logo name must match integration" if {
|
||||
"docs/website/data/integrations.yaml" in filenames
|
||||
|
||||
some filename in filenames
|
||||
ext := extension(filename)
|
||||
ext in logo_exts
|
||||
changes[filename].status == "added"
|
||||
logo_name := trim_suffix(basename(filename), concat("", [".", ext]))
|
||||
|
||||
integrations := {integration | some integration, _ in yaml.unmarshal(integrations_file).integrations}
|
||||
not logo_name in integrations
|
||||
}
|
||||
|
||||
deny contains sprintf("Integration '%v' missing required attribute '%v'", [name, attr]) if {
|
||||
"docs/website/data/integrations.yaml" in filenames
|
||||
|
||||
file := yaml.unmarshal(integrations_file)
|
||||
required := {"title", "description"}
|
||||
|
||||
some name, item in file.integrations
|
||||
some attr in (required - {key | some key, _ in item})
|
||||
}
|
||||
|
||||
deny contains sprintf("Integration '%v' references unknown software '%v' (i.e. not in 'software' object)", [name, software]) if {
|
||||
"docs/website/data/integrations.yaml" in filenames
|
||||
|
||||
file := yaml.unmarshal(integrations_file)
|
||||
software_list := object.keys(file.software)
|
||||
|
||||
some name, item in file.integrations
|
||||
some software in item.software
|
||||
not software in software_list
|
||||
}
|
||||
|
||||
deny contains sprintf("Integration '%v' references unknown organization '%v' (i.e. not in 'organizations' object)", [name, organization]) if {
|
||||
"docs/website/data/integrations.yaml" in filenames
|
||||
|
||||
file := yaml.unmarshal(integrations_file)
|
||||
organizations_list := object.keys(file.organizations)
|
||||
|
||||
some name, item in file.integrations
|
||||
some organization in item.inventors
|
||||
not organization in organizations_list
|
||||
}
|
||||
|
||||
deny contains sprintf("%s is an invalid YAML file: %s", [filename, content]) if {
|
||||
some filename, content in yaml_file_contents
|
||||
changes[filename].status in {"added", "modified"}
|
||||
@@ -120,8 +55,6 @@ deny contains sprintf("%s is an invalid JSON file: %s", [filename, content]) if
|
||||
not json.is_valid(content)
|
||||
}
|
||||
|
||||
integrations_file := get_file_in_pr("docs/website/data/integrations.yaml")
|
||||
|
||||
yaml_file_contents[filename] := get_file_in_pr(filename) if {
|
||||
some filename in filenames
|
||||
extension(filename) in {"yml", "yaml"}
|
||||
|
||||
@@ -4,183 +4,6 @@ import future.keywords.in
|
||||
|
||||
import data.files.deny
|
||||
|
||||
test_deny_logo_if_added_in_wrong_directory {
|
||||
expected := "Logo must be placed in docs/website/static/img/logos/integrations"
|
||||
expected in deny with input as [
|
||||
{
|
||||
"filename": "docs/website/data/integrations.yaml",
|
||||
"status": "modified",
|
||||
},
|
||||
{
|
||||
"filename": "docs/website/static/img/logos/example.png",
|
||||
"status": "added",
|
||||
},
|
||||
]
|
||||
}
|
||||
|
||||
test_allow_logo_if_added_in_correct_directory {
|
||||
integrations := yaml.marshal({"integrations": {"example": {
|
||||
"title": "My test integration",
|
||||
"description": "Testing",
|
||||
}}})
|
||||
|
||||
count(deny) == 0 with data.files.integrations_file as integrations with input as [
|
||||
{
|
||||
"filename": "docs/website/data/integrations.yaml",
|
||||
"status": "modified",
|
||||
},
|
||||
{
|
||||
"filename": "docs/website/static/img/logos/integrations/example.png",
|
||||
"status": "added",
|
||||
},
|
||||
]
|
||||
}
|
||||
|
||||
test_deny_logo_if_not_png_file {
|
||||
expected := "Logo must be a .png or .svg file"
|
||||
expected in deny with input as [
|
||||
{
|
||||
"filename": "docs/website/data/integrations.yaml",
|
||||
"status": "modified",
|
||||
},
|
||||
{
|
||||
"filename": "docs/website/static/img/logos/integrations/example.jpg",
|
||||
"status": "added",
|
||||
},
|
||||
]
|
||||
}
|
||||
|
||||
test_deny_logo_if_no_matching_integration {
|
||||
integrations := yaml.marshal({"integrations": {"my-integration": {
|
||||
"title": "My test integration",
|
||||
"description": "Testing",
|
||||
}}})
|
||||
|
||||
files := [
|
||||
{
|
||||
"filename": "docs/website/data/integrations.yaml",
|
||||
"status": "modified",
|
||||
},
|
||||
{
|
||||
"filename": "docs/website/static/img/logos/integrations/example.png",
|
||||
"status": "added",
|
||||
},
|
||||
]
|
||||
|
||||
expected := "Logo name must match integration"
|
||||
|
||||
expected in deny with data.files.integrations_file as integrations with input as files
|
||||
}
|
||||
|
||||
test_allow_logo_if_no_matching_integration {
|
||||
integrations := yaml.marshal({"integrations": {"my-integration": {
|
||||
"title": "My test integration",
|
||||
"description": "Testing",
|
||||
}}})
|
||||
|
||||
files := [
|
||||
{
|
||||
"filename": "docs/website/data/integrations.yaml",
|
||||
"status": "modified",
|
||||
},
|
||||
{
|
||||
"filename": "docs/website/static/img/logos/integrations/my-integration.png",
|
||||
"status": "added",
|
||||
},
|
||||
]
|
||||
|
||||
count(deny) == 0 with data.files.integrations_file as integrations with input as files
|
||||
}
|
||||
|
||||
test_deny_integration_if_missing_required_attribute {
|
||||
expected := "Integration 'my-integration' missing required attribute 'description'"
|
||||
files := [{"filename": "docs/website/data/integrations.yaml"}]
|
||||
integrations := yaml.marshal({"integrations": {"my-integration": {
|
||||
"title": "My test integration",
|
||||
"inventors": ["acmecorp"],
|
||||
}}})
|
||||
|
||||
expected in deny with data.files.integrations_file as integrations with input as files
|
||||
}
|
||||
|
||||
test_deny_integration_allowed_with_required_attributes {
|
||||
files := [{"filename": "docs/website/data/integrations.yaml"}]
|
||||
integrations := yaml.marshal({
|
||||
"integrations": {"my-integration": {
|
||||
"title": "My test integration",
|
||||
"description": "This is a test integration",
|
||||
"inventors": ["acmecorp"],
|
||||
}},
|
||||
"organizations": {"acmecorp": {"name": "AcmeCorp", "link": "https://acmecorp.example.org"}},
|
||||
})
|
||||
|
||||
count(deny) == 0 with data.files.integrations_file as integrations with input as files
|
||||
}
|
||||
|
||||
test_deny_unlisted_software {
|
||||
files := [{"filename": "docs/website/data/integrations.yaml"}]
|
||||
integrations := yaml.marshal({
|
||||
"integrations": {"my-integration": {
|
||||
"title": "My test integration",
|
||||
"description": "This is a test integration",
|
||||
"software": ["bitcoin-miner"],
|
||||
}},
|
||||
"software": {"kubernetes": {"name": "Kubernetes"}},
|
||||
})
|
||||
|
||||
expected := "Integration 'my-integration' references unknown software 'bitcoin-miner' (i.e. not in 'software' object)"
|
||||
|
||||
expected in deny with data.files.integrations_file as integrations with input as files
|
||||
}
|
||||
|
||||
test_allow_listed_software {
|
||||
files := [{"filename": "docs/website/data/integrations.yaml"}]
|
||||
integrations := yaml.marshal({
|
||||
"integrations": {"my-integration": {
|
||||
"title": "My test integration",
|
||||
"description": "This is a test integration",
|
||||
"software": ["kubernetes"],
|
||||
}},
|
||||
"software": {"kubernetes": {"name": "Kubernetes"}},
|
||||
})
|
||||
|
||||
count(deny) == 0 with data.files.integrations_file as integrations with input as files
|
||||
}
|
||||
|
||||
test_deny_unlisted_organization {
|
||||
files := [{"filename": "docs/website/data/integrations.yaml"}]
|
||||
integrations := yaml.marshal({
|
||||
"integrations": {"my-integration": {
|
||||
"title": "My test integration",
|
||||
"description": "This is a test integration",
|
||||
"software": ["kubernetes"],
|
||||
"inventors": ["acmecorp"],
|
||||
}},
|
||||
"software": {"kubernetes": {"name": "Kubernetes"}},
|
||||
"organizations": {"foobar": {"name": "FooBar", "link": "https://foobar.example.org"}},
|
||||
})
|
||||
|
||||
expected := "Integration 'my-integration' references unknown organization 'acmecorp' (i.e. not in 'organizations' object)"
|
||||
|
||||
expected in deny with data.files.integrations_file as integrations with input as files
|
||||
}
|
||||
|
||||
test_allow_listed_organization {
|
||||
files := [{"filename": "docs/website/data/integrations.yaml"}]
|
||||
integrations := yaml.marshal({
|
||||
"integrations": {"my-integration": {
|
||||
"title": "My test integration",
|
||||
"description": "This is a test integration",
|
||||
"software": ["kubernetes"],
|
||||
"inventors": ["acmecorp"],
|
||||
}},
|
||||
"software": {"kubernetes": {"name": "Kubernetes"}},
|
||||
"organizations": {"acmecorp": {"name": "AcmeCorp", "link": "https://acmecorp.example.org"}},
|
||||
})
|
||||
|
||||
count(deny) == 0 with data.files.integrations_file as integrations with input as files
|
||||
}
|
||||
|
||||
test_deny_invalid_yaml_file {
|
||||
expected := "invalid.yaml is an invalid YAML file: {null{}}"
|
||||
expected in deny with data.files.yaml_file_contents as {"invalid.yaml": "{null{}}"}
|
||||
|
||||
@@ -0,0 +1,189 @@
|
||||
package integrations
|
||||
|
||||
import future.keywords.contains
|
||||
import future.keywords.if
|
||||
import future.keywords.in
|
||||
|
||||
allowed_image_extensions := ["png", "svg"]
|
||||
|
||||
# check that all integrations have an image
|
||||
deny contains result if {
|
||||
some id, integration in input.integrations
|
||||
|
||||
# some integrations are allowed to have a missing image as no suitable image is available
|
||||
not integration.allow_missing_image == true
|
||||
|
||||
some _, ext in allowed_image_extensions
|
||||
|
||||
possible_filenames := {e |
|
||||
some i
|
||||
ext := allowed_image_extensions[i]
|
||||
|
||||
e := sprintf("%s.%s", [id, ext])
|
||||
}
|
||||
|
||||
possible_filenames - {i | i := input.images[_]} == possible_filenames
|
||||
|
||||
result := {
|
||||
"key": "integration_image",
|
||||
"message": sprintf("integration %s missing image in 'static/img/logos/integrations' with extension of: %v", [id, concat(",", allowed_image_extensions)]),
|
||||
}
|
||||
}
|
||||
|
||||
# check that all images have an integration
|
||||
deny contains result if {
|
||||
some _, image in input.images
|
||||
|
||||
id := split(image, ".")[0]
|
||||
|
||||
not id in object.keys(input.integrations)
|
||||
|
||||
result := {
|
||||
"key": "image_integration",
|
||||
"message": sprintf("image %s is not used by any integration page", [image]),
|
||||
}
|
||||
}
|
||||
|
||||
# check that all integrations have the required fields
|
||||
deny contains result if {
|
||||
some id, integration in input.integrations
|
||||
|
||||
missing_fields := {"title", "layout"} - object.keys(integration)
|
||||
|
||||
count(missing_fields) > 0
|
||||
|
||||
result := {
|
||||
"key": "fields",
|
||||
"message": sprintf("integration %s missing required fields: %v", [id, concat(", ", sort(missing_fields))]),
|
||||
}
|
||||
}
|
||||
|
||||
# check that all integrations have content
|
||||
deny contains result if {
|
||||
some id, integration in input.integrations
|
||||
|
||||
content := trim_space(object.get(integration, "content", ""))
|
||||
|
||||
content == ""
|
||||
|
||||
result := {
|
||||
"key": "content",
|
||||
"message": sprintf("integration %s has no content", [id]),
|
||||
}
|
||||
}
|
||||
|
||||
# check that all integrations have a layout set to integration-single
|
||||
deny contains result if {
|
||||
some id, integration in input.integrations
|
||||
|
||||
layout := object.get(integration, "layout", "")
|
||||
|
||||
layout != "integration-single"
|
||||
|
||||
result := {
|
||||
"key": "layout",
|
||||
"message": sprintf("integration %s does not have layout set to: integration-single", [id]),
|
||||
}
|
||||
}
|
||||
|
||||
# check that all integrations reference an existing organization
|
||||
deny contains result if {
|
||||
some id, integration in input.integrations
|
||||
|
||||
inventors := object.get(integration, "inventors", [])
|
||||
|
||||
some _, inventor in inventors
|
||||
|
||||
not inventor in object.keys(input.organizations)
|
||||
|
||||
result := {
|
||||
"key": "inventors",
|
||||
"message": sprintf("integration %s references organization %s which does not exist", [id, inventor]),
|
||||
}
|
||||
}
|
||||
|
||||
# check that all integrations reference existing software
|
||||
deny contains result if {
|
||||
some id, integration in input.integrations
|
||||
|
||||
softwares := object.get(integration, "software", [])
|
||||
|
||||
some _, software in softwares
|
||||
|
||||
not software in object.keys(input.softwares)
|
||||
|
||||
result := {
|
||||
"key": "software",
|
||||
"message": sprintf("integration %s references software %s which does not exist", [id, software]),
|
||||
}
|
||||
}
|
||||
|
||||
# check that softwares have required fields
|
||||
deny contains result if {
|
||||
some id, software in input.softwares
|
||||
|
||||
missing_fields := {"title", "layout", "link"} - object.keys(software)
|
||||
|
||||
count(missing_fields) > 0
|
||||
|
||||
result := {
|
||||
"key": "fields",
|
||||
"message": sprintf("software %s missing required fields: %v", [id, concat(", ", sort(missing_fields))]),
|
||||
}
|
||||
}
|
||||
|
||||
# check that organizations have required fields
|
||||
deny contains result if {
|
||||
some id, organization in input.organizations
|
||||
|
||||
missing_fields := {"title", "layout", "link"} - object.keys(organization)
|
||||
|
||||
count(missing_fields) > 0
|
||||
|
||||
result := {
|
||||
"key": "fields",
|
||||
"message": sprintf("organization %s missing required fields: %v", [id, concat(", ", sort(missing_fields))]),
|
||||
}
|
||||
}
|
||||
|
||||
# check that each organization has at least one integration
|
||||
deny contains result if {
|
||||
some id, organization in input.organizations
|
||||
|
||||
inventor_integrations := {i |
|
||||
some i, integration in input.integrations
|
||||
id in integration.inventors
|
||||
}
|
||||
speaker_integrations := {i |
|
||||
some i, integration in input.integrations
|
||||
some _, video in integration.videos
|
||||
|
||||
some _, speaker in video.speakers
|
||||
|
||||
speaker.organization == id
|
||||
}
|
||||
|
||||
count(inventor_integrations) + count(speaker_integrations) == 0
|
||||
|
||||
result := {
|
||||
"key": "orphaned_org",
|
||||
"message": sprintf("organization %s has no integrations", [id]),
|
||||
}
|
||||
}
|
||||
|
||||
# check that each software has at least one integration
|
||||
deny contains result if {
|
||||
some id, software in input.softwares
|
||||
|
||||
integrations := {i |
|
||||
some i, integration in input.integrations
|
||||
id in integration.software
|
||||
}
|
||||
|
||||
count(integrations) == 0
|
||||
|
||||
result := {
|
||||
"key": "orphaned_software",
|
||||
"message": sprintf("software %s has no integrations", [id]),
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,372 @@
|
||||
package integrations_test
|
||||
|
||||
import future.keywords.in
|
||||
|
||||
messages_for_key(key, output) = messages {
|
||||
messages := {m |
|
||||
some e
|
||||
output[e]
|
||||
|
||||
key in e
|
||||
|
||||
m := e.message
|
||||
}
|
||||
}
|
||||
|
||||
print_if(true, _, _, _) = true
|
||||
|
||||
print_if(false, key, false, output) := false {
|
||||
print("Exp:", {})
|
||||
print("Got: ", messages_for_key(key, output))
|
||||
}
|
||||
|
||||
print_if(false, key, expected, output) := false {
|
||||
is_string(expected)
|
||||
print("Exp:", expected)
|
||||
print("Got:", messages_for_key(key, output))
|
||||
}
|
||||
|
||||
test_integration_has_required_fields_missing {
|
||||
output := data.integrations.deny with input as {"integrations": {"regal": {}}}
|
||||
|
||||
key := "fields"
|
||||
message := "integration regal missing required fields: layout, title"
|
||||
|
||||
got := messages_for_key(key, output)
|
||||
|
||||
result := message in got
|
||||
|
||||
print_if(result, key, message, output)
|
||||
}
|
||||
|
||||
test_integration_has_required_fields_present {
|
||||
output := data.integrations.deny with input as {"integrations": {"regal": {"title": "Regal", "layout": "integration"}}}
|
||||
|
||||
key := "fields"
|
||||
message := "integration regal missing required fields: layout, title"
|
||||
|
||||
got := messages_for_key(key, output)
|
||||
|
||||
result := got == set()
|
||||
|
||||
print_if(result, key, false, output)
|
||||
}
|
||||
|
||||
test_integration_has_layout_missing {
|
||||
output := data.integrations.deny with input as {"integrations": {"regal": {}}}
|
||||
|
||||
key := "layout"
|
||||
message := "integration regal does not have layout set to: integration-single"
|
||||
|
||||
got := messages_for_key(key, output)
|
||||
|
||||
result := message in got
|
||||
|
||||
print_if(result, key, message, output)
|
||||
}
|
||||
|
||||
test_integration_has_layout_missing {
|
||||
output := data.integrations.deny with input as {"integrations": {"regal": {"layout": "wrong"}}}
|
||||
|
||||
key := "layout"
|
||||
message := "integration regal does not have layout set to: integration-single"
|
||||
|
||||
got := messages_for_key(key, output)
|
||||
|
||||
result := message in got
|
||||
|
||||
print_if(result, key, message, output)
|
||||
}
|
||||
|
||||
test_integration_has_layout_present {
|
||||
output := data.integrations.deny with input as {"integrations": {"regal": {"layout": "integration-single"}}}
|
||||
|
||||
key := "layout"
|
||||
|
||||
got := messages_for_key(key, output)
|
||||
|
||||
result := got == set()
|
||||
|
||||
print_if(result, key, false, output)
|
||||
}
|
||||
|
||||
test_integration_has_content_missing {
|
||||
output := data.integrations.deny with input as {"integrations": {"regal": {}}}
|
||||
|
||||
key := "content"
|
||||
message := "integration regal has no content"
|
||||
|
||||
got := messages_for_key(key, output)
|
||||
|
||||
result := message in got
|
||||
|
||||
print_if(result, key, message, output)
|
||||
}
|
||||
|
||||
test_integration_has_content_blank {
|
||||
output := data.integrations.deny with input as {"integrations": {"regal": {"content": "\t\t\n "}}}
|
||||
|
||||
key := "content"
|
||||
message := "integration regal has no content"
|
||||
|
||||
got := messages_for_key(key, output)
|
||||
|
||||
result := message in got
|
||||
|
||||
print_if(result, key, message, output)
|
||||
}
|
||||
|
||||
test_integration_has_content_present {
|
||||
output := data.integrations.deny with input as {"integrations": {"regal": {"content": "foobar"}}}
|
||||
|
||||
key := "content"
|
||||
got := messages_for_key(key, output)
|
||||
|
||||
result := got == set()
|
||||
|
||||
print_if(result, key, false, output)
|
||||
}
|
||||
|
||||
test_every_integration_has_image_missing {
|
||||
output := data.integrations.deny with input as {
|
||||
"images": ["reegal.png"],
|
||||
"integrations": {"regal": {}},
|
||||
}
|
||||
|
||||
key := "integration_image"
|
||||
message := "integration regal missing image in 'static/img/logos/integrations' with extension of: png,svg"
|
||||
|
||||
got := messages_for_key(key, output)
|
||||
|
||||
result := message in got
|
||||
|
||||
print_if(result, key, message, output)
|
||||
}
|
||||
|
||||
test_every_integration_has_image_present {
|
||||
output := data.integrations.deny with input as {
|
||||
"images": ["regal.png"],
|
||||
"integrations": {"regal": {}},
|
||||
}
|
||||
|
||||
key := "integration_image"
|
||||
got := messages_for_key(key, output)
|
||||
|
||||
result := got == set()
|
||||
|
||||
print_if(result, key, false, output)
|
||||
}
|
||||
|
||||
test_every_integration_has_image_missing_but_permitted {
|
||||
output := data.integrations.deny with input as {
|
||||
"images": ["reegal.png"],
|
||||
"integrations": {"regal": {"allow_missing_image": true}},
|
||||
}
|
||||
|
||||
key := "integration_image"
|
||||
|
||||
got := messages_for_key(key, output)
|
||||
|
||||
result := got == set()
|
||||
|
||||
print_if(result, key, false, output)
|
||||
}
|
||||
|
||||
test_every_image_has_integration_missing {
|
||||
output := data.integrations.deny with input as {
|
||||
"images": ["regal.png"],
|
||||
"integrations": {"foobar": {}},
|
||||
}
|
||||
|
||||
key := "image_integration"
|
||||
message := "image regal.png is not used by any integration page"
|
||||
|
||||
got := messages_for_key(key, output)
|
||||
|
||||
result := message in got
|
||||
|
||||
print_if(result, key, message, output)
|
||||
}
|
||||
|
||||
test_every_image_has_integration_present {
|
||||
output := data.integrations.deny with input as {
|
||||
"images": ["regal.png"],
|
||||
"integrations": {"regal": {}},
|
||||
}
|
||||
|
||||
key := "image_integration"
|
||||
got := messages_for_key(key, output)
|
||||
|
||||
result := got == set()
|
||||
|
||||
print_if(result, key, false, output)
|
||||
}
|
||||
|
||||
test_integration_organizations_missing {
|
||||
output := data.integrations.deny with input as {
|
||||
"organizations": {"stira": {}},
|
||||
"integrations": {"regal": {"inventors": ["styra"]}},
|
||||
}
|
||||
|
||||
key := "inventors"
|
||||
message := "integration regal references organization styra which does not exist"
|
||||
|
||||
got := messages_for_key(key, output)
|
||||
|
||||
result := message in got
|
||||
|
||||
print_if(result, key, message, output)
|
||||
}
|
||||
|
||||
test_integration_organizations_present {
|
||||
output := data.integrations.deny with input as {
|
||||
"organizations": {"styra": {}},
|
||||
"integrations": {"regal": {"inventors": ["styra"]}},
|
||||
}
|
||||
|
||||
key := "inventors"
|
||||
got := messages_for_key(key, output)
|
||||
|
||||
result := got == set()
|
||||
|
||||
print_if(result, key, false, output)
|
||||
}
|
||||
|
||||
test_integration_softwares_missing {
|
||||
output := data.integrations.deny with input as {
|
||||
"softwares": {"mars": {}},
|
||||
"integrations": {"regal": {"software": ["terraform"]}},
|
||||
}
|
||||
|
||||
key := "software"
|
||||
message := "integration regal references software terraform which does not exist"
|
||||
|
||||
got := messages_for_key(key, output)
|
||||
|
||||
result := message in got
|
||||
|
||||
print_if(result, key, message, output)
|
||||
}
|
||||
|
||||
test_integration_softwares_present {
|
||||
output := data.integrations.deny with input as {
|
||||
"softwares": {"terraform": {}},
|
||||
"integrations": {"regal": {"software": ["terraform"]}},
|
||||
}
|
||||
|
||||
key := "software"
|
||||
got := messages_for_key(key, output)
|
||||
|
||||
result := got == set()
|
||||
|
||||
print_if(result, key, false, output)
|
||||
}
|
||||
|
||||
test_software_has_required_fields_missing {
|
||||
output := data.integrations.deny with input as {"softwares": {"terraform": {}}}
|
||||
|
||||
key := "fields"
|
||||
message := "software terraform missing required fields: layout, link, title"
|
||||
|
||||
got := messages_for_key(key, output)
|
||||
|
||||
result := message in got
|
||||
|
||||
print_if(result, key, message, output)
|
||||
}
|
||||
|
||||
test_software_has_required_fields_present {
|
||||
output := data.integrations.deny with input as {"softwares": {"terraform": {"layout": "software-single", "link": "https://www.terraform.io/", "title": "Terraform"}}}
|
||||
|
||||
key := "fields"
|
||||
|
||||
got := messages_for_key(key, output)
|
||||
|
||||
result := got == set()
|
||||
|
||||
print_if(result, key, false, output)
|
||||
}
|
||||
|
||||
test_organization_has_required_labels {
|
||||
output := data.integrations.deny with input as {"organizations": {"styra": {}}}
|
||||
|
||||
key := "fields"
|
||||
message := "organization styra missing required fields: layout, link, title"
|
||||
|
||||
got := messages_for_key(key, output)
|
||||
|
||||
result := message in got
|
||||
|
||||
print_if(result, key, message, output)
|
||||
}
|
||||
|
||||
test_organization_has_required_fields_present {
|
||||
output := data.integrations.deny with input as {"organizations": {"styra": {"layout": "organization-single", "link": "https://styra.com/", "title": "Styra"}}}
|
||||
|
||||
key := "fields"
|
||||
|
||||
got := messages_for_key(key, output)
|
||||
|
||||
result := got == set()
|
||||
|
||||
print_if(result, key, false, output)
|
||||
}
|
||||
|
||||
test_organization_has_one_or_more_integrations_none {
|
||||
output := data.integrations.deny with input as {"organizations": {"foobar": {}}, "integrations": {}}
|
||||
|
||||
key := "orphaned_org"
|
||||
message := "organization foobar has no integrations"
|
||||
|
||||
got := messages_for_key(key, output)
|
||||
|
||||
result := message in got
|
||||
|
||||
print_if(result, key, message, output)
|
||||
}
|
||||
|
||||
test_organization_has_one_or_more_integrations_one {
|
||||
output := data.integrations.deny with input as {"organizations": {"foobaz": {}}, "integrations": {"foobar": {"inventors": ["foobaz"]}}}
|
||||
|
||||
key := "orphaned_org"
|
||||
got := messages_for_key(key, output)
|
||||
|
||||
result := got == set()
|
||||
|
||||
print_if(result, key, false, output)
|
||||
}
|
||||
|
||||
test_organization_has_one_or_more_integrations_speaker {
|
||||
output := data.integrations.deny with input as {"organizations": {"foobaz": {}}, "integrations": {"foobar": {"videos": [{"speakers": [{"organization": "foobaz"}]}]}}}
|
||||
|
||||
key := "orphaned_org"
|
||||
got := messages_for_key(key, output)
|
||||
|
||||
result := got == set()
|
||||
|
||||
print_if(result, key, false, output)
|
||||
}
|
||||
|
||||
test_software_has_one_or_more_integrations_none {
|
||||
output := data.integrations.deny with input as {"softwares": {"foobar": {}}, "integrations": {}}
|
||||
|
||||
key := "orphaned_software"
|
||||
message := "software foobar has no integrations"
|
||||
|
||||
got := messages_for_key(key, output)
|
||||
|
||||
result := message in got
|
||||
|
||||
print_if(result, key, message, output)
|
||||
}
|
||||
|
||||
test_software_has_one_or_more_integrations_one {
|
||||
output := data.integrations.deny with input as {"softwares": {"foobaz": {}}, "integrations": {"foobar": {"software": ["foobaz"]}}}
|
||||
|
||||
key := "orphaned_software"
|
||||
got := messages_for_key(key, output)
|
||||
|
||||
result := got == set()
|
||||
|
||||
print_if(result, key, false, output)
|
||||
}
|
||||
+64
-51
@@ -14,8 +14,8 @@ the website.
|
||||
directory. This content is versioned for each release and should have all images
|
||||
and code snippets alongside the markdown content files.
|
||||
|
||||
[website/data/integrations.yaml](./website/data/integrations.yaml) - Source for the
|
||||
integrations index. See [Integration Index](#integration-index) below for more details.
|
||||
[content/integrations/](./content/integrations) - Source for the
|
||||
OPA Ecosystem page. See [OPA Ecosystem](#opa-ecosystem) below for more details.
|
||||
|
||||
## Website Components
|
||||
|
||||
@@ -287,73 +287,86 @@ another group's module when evaluating (e.g. so that they can be imported).
|
||||
|
||||
> If a query isn't specified for the output's group, when other modules are included the default becomes `data` instead of `data.<package name>`.
|
||||
|
||||
# Integration Index
|
||||
# OPA Ecosystem
|
||||
|
||||
The integration index makes it easy to find either a specific integration with OPA
|
||||
or to browse the integrations with OPA within a particular category. And it pulls
|
||||
information about that integration (e.g. blogs, videos, tutorials, code) into a
|
||||
single place while allowing integration authors to maintain the code wherever they like.
|
||||
The [OPA Ecosystem](https://www.openpolicyagent.org/docs/latest/ecosystem/)
|
||||
makes it easy to find either a specific integration with OPA
|
||||
or to browse the integrations with OPA within a particular category. It pulls
|
||||
information about different integrations (e.g. blogs, videos, tutorials, code) into a
|
||||
single place while allowing integration authors to update the docs content as needed.
|
||||
|
||||
## Schema
|
||||
|
||||
The schema of integrations.yaml has the following highlevel entries, each of which is self-explanatory.
|
||||
- integrations
|
||||
- organizations
|
||||
- software
|
||||
Source information for the OPA Ecosystem is stored in the following places:
|
||||
|
||||
Each entry is an object where keys are unique identifiers for each subentry.
|
||||
Organizations and Software are self-explanatory by inspection. The schema for integrations is as follows.
|
||||
- [content/integrations/](./content/integrations) - each file creates a page in the OPA Ecosystem for a particular integration.
|
||||
- [content/organizations/](./content/organizations) - each file is a page for organizations and companies associated with integrations.
|
||||
- [content/softwares/](./content/softwares) - each file is for software categories related to integrations.
|
||||
|
||||
- title: string
|
||||
- description: string
|
||||
- software: array of strings
|
||||
- labels: collection of key/value pairs.
|
||||
- tutorials: array of links
|
||||
- code: array of links
|
||||
- inventors: array of either
|
||||
- string (organization name)
|
||||
- object with fields
|
||||
- name: string
|
||||
- organization: string
|
||||
- videos: array of either
|
||||
- link
|
||||
- object with fields
|
||||
- title: string
|
||||
- speakers: array of name/organization objects
|
||||
- venue: string
|
||||
- link: string
|
||||
- blogs: array of links
|
||||
Integrations should have a file in `content/integrations/` with the following schema:
|
||||
|
||||
The UI for this is currently hosted at [https://openpolicyagent.org/docs/latest/ecosystem/](https://openpolicyagent.org/docs/latest/ecosystem/)
|
||||
```md
|
||||
---
|
||||
layout: integration-single # required to be set and to this value
|
||||
title: <integration name>
|
||||
software:
|
||||
- <related software>
|
||||
- <related software>
|
||||
inventors:
|
||||
- <inventor name>
|
||||
- <inventor name>
|
||||
tutorials: # optional, links to tutorials for the integration
|
||||
- https://example.com/tutorial
|
||||
code: # optional, links to code for the integration
|
||||
- https://github.com/...
|
||||
blogs: # optional, links to blog posts for the integration
|
||||
- https://example.com/blog/1
|
||||
videos: # optional, links to videos for the integration
|
||||
- title: <video title>
|
||||
speakers:
|
||||
- name: <speaker name>
|
||||
organization: <speaker organization>
|
||||
venue: <venue>
|
||||
link: <link>
|
||||
---
|
||||
Description of the integration (required)
|
||||
```
|
||||
|
||||
The future plan is to use the following labels to generate categories of integrations.
|
||||
Any `inventor` that is not already in `content/organizations/` will need to be added too in `content/organizations/`.
|
||||
Organizations have the following format:
|
||||
|
||||
- layer: which layer of the stack does this belong to
|
||||
- category: which kind of component within that layer is this
|
||||
- type: what kind of integration this is. Either `enforcement` or `poweredbyopa`. `enforcement` is the default
|
||||
if `type` is missing. `poweredbyopa` is intended to be integrations built using OPA that are not tied to a
|
||||
particular layer of the stack. This distinction is the most ambiguous and may change.
|
||||
```md
|
||||
---
|
||||
link: https://example.com
|
||||
title: <organization name>
|
||||
layout: organization-single # required to be set and to this value
|
||||
---
|
||||
```
|
||||
|
||||
As of now the labels are only displayed for each entry.
|
||||
Any `software` that is not already in `content/softwares/` will need to be added too in `content/softwares/`.
|
||||
Software categories have the following format:
|
||||
|
||||
```md
|
||||
---
|
||||
link: https://example.com
|
||||
title: <software name>
|
||||
layout: software-single # required to be set and to this value
|
||||
---
|
||||
```
|
||||
|
||||
## Logos
|
||||
|
||||
For each entry in the [integrations.yaml](./website/data/integrations.yaml)
|
||||
integrations section the UI will use a PNG or SVG logo with the same name as the key from
|
||||
[./website/static/img/logos/integrations](./website/static/img/logos/integrations)
|
||||
For each file in under [content/integrations/](./website/content/integrations)
|
||||
a png or svg logo with the same name must be placed in `./website/static/img/logos/integrations`.
|
||||
|
||||
For example:
|
||||
|
||||
```yaml
|
||||
integrations:
|
||||
my-cool-integration:
|
||||
...
|
||||
```md
|
||||
# content/integrations/my-cool-integration.md
|
||||
```
|
||||
|
||||
Would need a file called `my-cool-integration.png` at `./website/static/img/logos/integrations/my-cool-integration.png`
|
||||
(or `my-cool-integration.svg` in the same location).
|
||||
|
||||
If it doesn't exist the OPA logo will be shown by default.
|
||||
Would need a file called `my-cool-integration.(png|svg)` at
|
||||
`./website/static/img/logos/integrations/my-cool-integration.(png|svg)`.
|
||||
|
||||
## Google Analytics
|
||||
|
||||
|
||||
@@ -19,7 +19,7 @@ Docs for the OPA sub-projects each have their own home. Check out their docs to
|
||||
- [devel/](https://github.com/open-policy-agent/opa/blob/main/docs/devel) - Developer documentation for OPA (not part of the website)
|
||||
- [website/](https://github.com/open-policy-agent/opa/blob/main/docs/website) - This directory contains all of the Markdown, HTML, Sass/CSS, and other assets needed to build the [openpolicyagent.org](https://openpolicyagent.org) website. See the section below for steps to build the site and test documentation changes locally. This content is not versioned for each release, it is common scaffolding for the website.
|
||||
- [content/](https://github.com/open-policy-agent/opa/blob/main/docs/content) - The raw OPA documentation can be found under the directory. This content is versioned for each release and should have all images and code snippets alongside the markdown content files.
|
||||
- [website/data/integrations.yaml](https://github.com/open-policy-agent/opa/blob/main/docs/website/data/integrations.yaml) - Source for the integrations index. See [Integration Index](https://github.com/open-policy-agent/opa/blob/main/docs/README.md#integration-index) below for more details.
|
||||
- [content/integrations, content/organizations, content/softwares](https://github.com/open-policy-agent/opa/blob/main/docs/content) - the source for data used to generate the [OPA Ecosystem](https://www.openpolicyagent.org/docs/latest/ecosystem/)
|
||||
|
||||
## Markdown Page Structure
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: "OPA Ecosystem"
|
||||
layout: ecosystem-section
|
||||
kind: support
|
||||
edit_link: https://github.com/open-policy-agent/opa/edit/main/docs/website/data/integrations.yaml
|
||||
edit_link: https://github.com/open-policy-agent/opa/tree/main/docs#opa-ecosystem
|
||||
categories:
|
||||
- key: rego
|
||||
title: Rego Language
|
||||
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: Alfred
|
||||
subtitle: Self-hosted OPA playground
|
||||
labels:
|
||||
layer: network
|
||||
category: application
|
||||
software:
|
||||
- alfred
|
||||
inventors:
|
||||
- dolevf
|
||||
code:
|
||||
- https://github.com/dolevf/Open-Policy-Agent-Alfred
|
||||
docs_features:
|
||||
learning-rego:
|
||||
note: |
|
||||
Similar to the public [OPA Playground](https://play.openpolicyagent.org/),
|
||||
Alfred can be used to learn Rego interactively in an environment that
|
||||
can't use the public playground. Read about
|
||||
[installation](https://github.com/dolevf/Open-Policy-Agent-Alfred#how-to-install).
|
||||
layout: integration-single
|
||||
---
|
||||
Alfred introduces a local graphical user interface to interact with Open Policy Agent and acts as an alternative to OPA's playground, allowing the user to keep information related to policy testing locally.
|
||||
|
||||
@@ -0,0 +1,12 @@
|
||||
---
|
||||
title: Alluxio
|
||||
labels:
|
||||
category: authorization
|
||||
type: poweredbyopa
|
||||
tutorials:
|
||||
- https://docs.alluxio.io/ee/user/2.10.0/en/security/OpenPolicyAgent-Integration.html
|
||||
inventors:
|
||||
- alluxio
|
||||
layout: integration-single
|
||||
---
|
||||
Alluxio is an open source data orchestration technology for analytics and AI for the cloud. Alluxio can integrate with OPA and delegate all permission checks to OPA.
|
||||
@@ -0,0 +1,12 @@
|
||||
---
|
||||
title: ANTLR Grammar
|
||||
labels:
|
||||
category: utilities
|
||||
layer: rego
|
||||
code:
|
||||
- https://github.com/antlr/grammars-v4
|
||||
inventors:
|
||||
- independent
|
||||
layout: integration-single
|
||||
---
|
||||
ANTLR4 grammar for Rego.
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: Authorization Integration with Apache APISIX
|
||||
software:
|
||||
- apache-apisix
|
||||
labels:
|
||||
category: gateway
|
||||
layer: network
|
||||
code:
|
||||
- https://github.com/apache/apisix
|
||||
blogs:
|
||||
- https://apisix.apache.org/blog/2021/12/24/open-policy-agent
|
||||
- https://medium.com/@ApacheAPISIX/apache-apisix-integrates-with-open-policy-agent-to-enrich-its-ecosystem-15569fe3ab9c
|
||||
docs_features:
|
||||
rest-api-integration:
|
||||
note: |
|
||||
Apache APISIX routes can be configured to call an OPA instance over
|
||||
the REST API.
|
||||
[This blog post](https://apisix.apache.org/blog/2021/12/24/open-policy-agent/)
|
||||
explains how such a configuration can be achieved.
|
||||
layout: integration-single
|
||||
---
|
||||
Apache APISIX provides a plugin for delegating fine-grained authorization decisions to OPA.
|
||||
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: Aserto
|
||||
labels:
|
||||
category: authorization
|
||||
layer: application
|
||||
type: poweredbyopa
|
||||
inventors:
|
||||
- aserto
|
||||
code:
|
||||
- https://github.com/aserto-dev
|
||||
- https://github.com/opcr-io
|
||||
tutorials:
|
||||
- https://docs.aserto.com/docs
|
||||
blogs:
|
||||
- https://www.aserto.com/blog/how-do-aserto-rego-policies-work
|
||||
- https://www.aserto.com/blog/testing-rego-policies
|
||||
- https://www.aserto.com/blog/aserto-on-aserto-an-opa-authorization-policy-for-aserto-tenants
|
||||
- https://www.aserto.com/blog/rego-getting-started
|
||||
videos:
|
||||
- https://www.youtube.com/watch?v=RJkgmdjJn_w
|
||||
layout: integration-single
|
||||
---
|
||||
Aserto is a cloud-native authorization service that makes it easy to add permissions and RBAC to your SaaS applications and APIs.
|
||||
Aserto is based on the Open Policy Agent.
|
||||
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
title: ASP.NET Core
|
||||
labels:
|
||||
category: application
|
||||
layer: network
|
||||
code:
|
||||
- https://github.com/build-security/OPA-AspDotNetCore-Middleware
|
||||
inventors:
|
||||
- build.security
|
||||
layout: integration-single
|
||||
---
|
||||
Use ASP.NET Core to create web apps and services that are fast, secure, cross-platform, and cloud-based.
|
||||
OPA can be used to implement authorization policies for APIs used in the ASP.NET Core framework.
|
||||
|
||||
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: Atmos
|
||||
software:
|
||||
- aws
|
||||
- gcp
|
||||
- terraform
|
||||
- helm
|
||||
inventors:
|
||||
- cloudposse
|
||||
labels:
|
||||
category: Infrastructure as Code
|
||||
type: poweredbyopa
|
||||
tutorials:
|
||||
- https://atmos.tools/core-concepts/components/validation/#open-policy-agent-opa
|
||||
code:
|
||||
- https://github.com/cloudposse/atmos
|
||||
docs_features:
|
||||
terraform:
|
||||
note: |
|
||||
Atmos can validate Terraform stack before applying them. This is done
|
||||
using the `validate component` command
|
||||
[documented here](https://atmos.tools/cli/commands/validate/component).
|
||||
layout: integration-single
|
||||
---
|
||||
Workflow automation tool for DevOps. Keep configuration DRY with hierarchical imports of configurations, inheritance, and WAY more.
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: Awesome OPA List
|
||||
software: []
|
||||
labels:
|
||||
category: learning
|
||||
type: poweredbyopa
|
||||
code:
|
||||
- https://github.com/StyraInc/awesome-opa
|
||||
inventors:
|
||||
- styra
|
||||
docs_features:
|
||||
learning-rego:
|
||||
note: |
|
||||
The Awesome OPA project maintains a list of
|
||||
[policy packages](https://github.com/StyraInc/awesome-opa#policy-packages),
|
||||
and [editor integrations](https://github.com/StyraInc/awesome-opa#ide-and-editor-integrations)
|
||||
which can be helpful references for learning Rego.
|
||||
layout: integration-single
|
||||
allow_missing_image: true
|
||||
---
|
||||
A curated list of awesome OPA related tools, frameworks and articles.
|
||||
@@ -0,0 +1,10 @@
|
||||
---
|
||||
title: AWS API Gateway
|
||||
labels:
|
||||
category: servicemesh
|
||||
layer: gateway
|
||||
code:
|
||||
- https://github.com/zotoio/sls-lambda-opa
|
||||
layout: integration-single
|
||||
---
|
||||
The AWS API Gateway controls API traffic for your application running on AWS. OPA can be configured as an external authorizer for that Gateway to implement authorization policies on APIs.
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: AWS CloudFormation Hook
|
||||
software:
|
||||
- aws
|
||||
- cloudformation
|
||||
labels:
|
||||
type: poweredbyopa
|
||||
tutorials:
|
||||
- https://www.openpolicyagent.org/docs/latest/aws-cloudformation-hooks/
|
||||
code:
|
||||
- https://github.com/StyraInc/opa-aws-cloudformation-hook
|
||||
blogs:
|
||||
- https://blog.styra.com/blog/the-opa-aws-cloudformation-hook
|
||||
inventors:
|
||||
- styra
|
||||
docs_features:
|
||||
rest-api-integration:
|
||||
note: |
|
||||
The OPA CloudFormation Hook uses AWS Lambda to consult an OPA instance
|
||||
using the REST API before allowing a CloudFormation stack to be created.
|
||||
|
||||
Read [the tutorial](https://www.openpolicyagent.org/docs/latest/aws-cloudformation-hooks/)
|
||||
here in the OPA documentation.
|
||||
layout: integration-single
|
||||
---
|
||||
AWS CloudFormation Hook that uses OPA to make policy decisions on infrastructure provisioned via AWS CloudFormation
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: Boomerang Bosun Policy Gating
|
||||
labels:
|
||||
type: poweredbyopa
|
||||
layer: application
|
||||
code:
|
||||
- https://www.useboomerang.io/
|
||||
- https://github.com/boomerang-io
|
||||
inventors:
|
||||
- ibm
|
||||
- boomerang
|
||||
docs_features:
|
||||
rest-api-integration:
|
||||
note: |
|
||||
The
|
||||
[Boomerang Bosun Service](https://github.com/boomerang-io/bosun.service.policy)
|
||||
component interacts with an OPA instance over the REST API to evaluate
|
||||
policy during CICD runs.
|
||||
layout: integration-single
|
||||
---
|
||||
Boomerang Bosun is a policy-based gating system that combines Policy Templates with Rules and data to validate Gates.
|
||||
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: Bottle Application Authorization
|
||||
labels:
|
||||
layer: network
|
||||
category: application
|
||||
inventors:
|
||||
- dolevf
|
||||
software:
|
||||
- bottle
|
||||
code:
|
||||
- https://github.com/dolevf/bottle-acl-openpolicyagent
|
||||
blogs:
|
||||
- https://blog.lethalbit.com/open-policy-agent-for-bottle-web-framework/
|
||||
docs_features:
|
||||
rest-api-integration:
|
||||
note: |
|
||||
This sample python application calls has a middleware to call OPA
|
||||
before processing each request. See the
|
||||
[example code](https://github.com/dolevf/bottle-acl-openpolicyagent/blob/00a4336/main.py#L37).
|
||||
layout: integration-single
|
||||
---
|
||||
This integration demonstrates using Open Policy Agent to perform API authorization for a Python application backed by Bottle.
|
||||
Bottle is a fast, simple and lightweight WSGI micro web-framework for Python.
|
||||
|
||||
@@ -0,0 +1,16 @@
|
||||
---
|
||||
title: Carbonetes - BrainIAC
|
||||
software:
|
||||
- github
|
||||
- brainiac
|
||||
labels:
|
||||
layer: Infrastructure
|
||||
category: security
|
||||
type: poweredbyopa
|
||||
code:
|
||||
- https://github.com/carbonetes/brainiac
|
||||
inventors:
|
||||
- carbonetes
|
||||
layout: integration-single
|
||||
---
|
||||
BrainIAC uses static code analysis to analyze IAC code to detect security issues before deployment. This tool can scan for issues like security policy misconfigurations, insecure cloud-based services, and compliance issues. The BrainIAC tool performs a comprehensive code scan and generates reports containing detailed insights into the identified issues..
|
||||
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: Ceph Object Storage Authorization
|
||||
software:
|
||||
- ceph
|
||||
labels:
|
||||
category: object
|
||||
layer: data
|
||||
tutorials:
|
||||
- https://docs.ceph.com/docs/master/radosgw/opa/
|
||||
- https://www.katacoda.com/styra/scenarios/opa-ceph
|
||||
inventors:
|
||||
- styra
|
||||
- redhat
|
||||
videos:
|
||||
- https://www.youtube.com/watch?v=9m4FymEvOqM&feature=share
|
||||
docs_feature:
|
||||
rest-api-integration:
|
||||
note: |
|
||||
The Ceph Object Gateway implements a native integration with OPA using
|
||||
the REST API.
|
||||
The [integration is documented](https://docs.ceph.com/en/latest/radosgw/opa/)
|
||||
in the Ceph docs.
|
||||
layout: integration-single
|
||||
---
|
||||
Ceph is a highly scalable distributed storage solution that uniquely delivers object, block, and file storage in one unified system. OPA provides fine-grained, context-aware authorization of the information stored within Ceph.
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: Chef Automate
|
||||
subtitle: Operational Visibility Dashboard
|
||||
tutorials:
|
||||
- https://github.com/chef/automate/tree/master/components/authz-service#authz-with-opa
|
||||
videos:
|
||||
- title: 'OPA in Practice: From Angular to OPA in Chef Automate'
|
||||
speakers:
|
||||
- name: Michael Sorens
|
||||
organization: chef
|
||||
venue: OPA Summit at Kubecon San Diego 2019
|
||||
link: https://www.youtube.com/watch?v=jrrW855xL3s
|
||||
docs_features:
|
||||
go-integration:
|
||||
note: |
|
||||
Chef Automate uses the Go Rego API to evaluate authorization policies
|
||||
controlling access to its own API endpoints. The feature is
|
||||
[documented here](https://github.com/chef/automate/tree/master/components/authz-service#authz-with-opa).
|
||||
layout: integration-single
|
||||
allow_missing_image: true
|
||||
---
|
||||
Application require authorization decisions made at the API gateway, frontend, backend, and database.
|
||||
OPA helps developers decouple authorization logic from application code, define a custom authorization model
|
||||
that enables end-users to control tenant permissions, and enforce that policy across the different components of the
|
||||
application (gateway, frontend, backend, database).
|
||||
|
||||
@@ -0,0 +1,13 @@
|
||||
---
|
||||
title: CircleCI
|
||||
labels:
|
||||
category: tooling
|
||||
layer: cicd
|
||||
type: poweredbyopa
|
||||
tutorials:
|
||||
- https://circleci.com/docs/config-policy-management-overview/
|
||||
inventors:
|
||||
- circleci
|
||||
layout: integration-single
|
||||
---
|
||||
Use config policy management to create organization-level policies to impose rules and scopes around which configuration elements are required, allowed, not allowed etc.
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
title: Kubernetes Admission Control using Vulnerability Scanning
|
||||
software:
|
||||
- kubernetes
|
||||
- clair
|
||||
labels:
|
||||
layer: orchestration
|
||||
category: containers
|
||||
datasource: clair
|
||||
code:
|
||||
- https://github.com/open-policy-agent/contrib/tree/master/image_enforcer
|
||||
tutorials:
|
||||
- https://github.com/open-policy-agent/contrib/blob/master/image_enforcer/README.md
|
||||
docs_features:
|
||||
rest-api-integration:
|
||||
note: |
|
||||
This example project in
|
||||
[OPA contrib](https://github.com/open-policy-agent/contrib/tree/main/image_enforcer)
|
||||
uses OPA over the REST API to enforce admission policy based on
|
||||
vulnerability scanning results.
|
||||
kubernetes:
|
||||
note: |
|
||||
This example project in
|
||||
[OPA contrib](https://github.com/open-policy-agent/contrib/tree/main/image_enforcer)
|
||||
uses OPA to enforce admission policy in Kubernetes.
|
||||
layout: integration-single
|
||||
---
|
||||
Admission control policies in Kubernetes can be augmented with
|
||||
vulnerability scanning results to make more informed decisions.
|
||||
This integration demonstrates how to integrate CoreOS Clair with OPA and
|
||||
run it as an admission controller.
|
||||
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
title: App authorization for Clojure
|
||||
software:
|
||||
- clojure
|
||||
labels:
|
||||
layer: network
|
||||
category: application
|
||||
code:
|
||||
- https://github.com/anderseknert/clj-opa
|
||||
inventors:
|
||||
- styra
|
||||
layout: integration-single
|
||||
---
|
||||
Authorization middleware for Ring based apps and other utilities for working with OPA in Clojure.
|
||||
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: Cloudflare Worker Enforcement of OPA Policies Using Wasm
|
||||
software:
|
||||
- cloudflare
|
||||
labels:
|
||||
layer: application
|
||||
category: serverless
|
||||
code:
|
||||
- https://github.com/open-policy-agent/contrib/tree/master/wasm/cloudflare-worker
|
||||
tutorials:
|
||||
- https://github.com/open-policy-agent/contrib/blob/master/wasm/cloudflare-worker/README.md
|
||||
docs_features:
|
||||
wasm-integration:
|
||||
note: |
|
||||
This example project in
|
||||
[OPA contrib](https://github.com/open-policy-agent/contrib/tree/main/wasm/cloudflare-worker)
|
||||
uses the
|
||||
[NodeJS OPA Wasm Module](https://github.com/open-policy-agent/npm-opa-wasm)
|
||||
to enforce policy at the edge of Cloudflare's network.
|
||||
layout: integration-single
|
||||
---
|
||||
Cloudflare Workers are a serverless platform that supports Wasm.
|
||||
This integration uses OPA's Wasm compiler to generate code enforced at the edge of Cloudflare's network.
|
||||
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: Conftest
|
||||
subtitle: Rego policy for configuration files
|
||||
labels:
|
||||
type: poweredbyopa
|
||||
layer: configuration
|
||||
code:
|
||||
- https://github.com/open-policy-agent/conftest
|
||||
software:
|
||||
- kustomize
|
||||
- terraform
|
||||
- aws
|
||||
- toml
|
||||
- docker
|
||||
tutorials:
|
||||
- https://www.conftest.dev
|
||||
- https://www.conftest.dev/examples/
|
||||
videos:
|
||||
- title: Applying Policy Throughout the Application Lifecycle with Open Policy Agent
|
||||
speakers:
|
||||
- name: Gareth Rushgrove
|
||||
organization: snyk
|
||||
venue: Kubecon San Diego 2019
|
||||
link: https://www.youtube.com/watch?v=cXfsaE6RKfc
|
||||
- title: 'Terraform Code Reviews: Supercharged with Conftest'
|
||||
speakers:
|
||||
- name: Jay Wallace
|
||||
organization: doordash
|
||||
venue: Hashitalks 2020
|
||||
link: https://www.youtube.com/watch?v=ziKT-ZjZ7mM
|
||||
docs_features:
|
||||
policy-testing:
|
||||
note: |
|
||||
Conftest supports unit testing of policy and has a number of extra language
|
||||
features for working with configuration files. The functionality is
|
||||
[documented here](https://www.conftest.dev/#testingverifying-policies).
|
||||
go-integration:
|
||||
note: |
|
||||
Conftest is written in Go and uses the
|
||||
[Rego Go API](https://www.openpolicyagent.org/docs/latest/integration/#integrating-with-the-go-api).
|
||||
opa-bundles:
|
||||
note: |
|
||||
Conftest supports the loading of policy in a bundle format. The feature
|
||||
is [documented here](https://www.conftest.dev/sharing/).
|
||||
terraform:
|
||||
note: |
|
||||
Conftest has generic support for Terraform source files defined in HCL.
|
||||
There is an example provided here on
|
||||
[GitHub](https://github.com/open-policy-agent/conftest/tree/master/examples/hcl2).
|
||||
layout: integration-single
|
||||
---
|
||||
Conftest is a utility built on top of OPA to help you write tests against structured configuration data.
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
title: CoreDNS Authorization
|
||||
labels:
|
||||
layer: network
|
||||
category: dns
|
||||
software:
|
||||
- coredns
|
||||
code:
|
||||
- https://github.com/coredns/policy
|
||||
inventors:
|
||||
- infoblox
|
||||
layout: integration-single
|
||||
---
|
||||
CoreDNS is a cloud-native DNS server written in Go. OPA can be used as a plugin to filter queries and responses.
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: Container Signing, Verification and Storage in an OCI registry
|
||||
labels:
|
||||
category: security
|
||||
layer: application
|
||||
software:
|
||||
- cosign
|
||||
inventors:
|
||||
- sigstore
|
||||
code:
|
||||
- https://docs.sigstore.dev/cosign/attestation#validate-in-toto-attestations
|
||||
- https://github.com/sigstore/cosign-gatekeeper-provider
|
||||
vides:
|
||||
- https://www.youtube.com/watch?v=gCi9_4NYyR0
|
||||
docs_features:
|
||||
go-integration:
|
||||
note: |
|
||||
Cosign In-Toto attestations can be
|
||||
[written in Rego](https://docs.sigstore.dev/cosign/attestation/#cosign-custom-predicate-type-and-rego-policy),
|
||||
these are evaluated in the Cosign binary using the Go API.
|
||||
layout: integration-single
|
||||
---
|
||||
Cosign is a tool for container image signing and verifying maintained under the Project Sigstore
|
||||
in collaboration with the Linux Foundation. Among other features, Cosign supports KMS signing,
|
||||
built-in binary transparency, and timestamping service with Rekor and Kubernetes policy enforcement.
|
||||
|
||||
@@ -0,0 +1,18 @@
|
||||
---
|
||||
title: Library-based Microservice Authorization
|
||||
labels:
|
||||
category: servicemesh
|
||||
layer: library
|
||||
videos:
|
||||
- title: How Netflix is Solving Authorization Across Their Cloud
|
||||
speakers:
|
||||
- name: Manish Mehta
|
||||
organization: netflix
|
||||
- name: Torin Sandall
|
||||
organization: styra
|
||||
venue: Kubecon Austin 2017
|
||||
link: https://www.youtube.com/watch?v=R6tUNpRpdnY
|
||||
layout: integration-single
|
||||
allow_missing_image: true
|
||||
---
|
||||
Microservice authorization can be enforced through a network proxy like Envoy/Istio/Linkerd/... or can be enforced by modifying the microservice code to use a common library. In both cases OPA makes the authorization decision that the network proxy or the library enforce.
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: Dapr
|
||||
software:
|
||||
- dapr
|
||||
labels:
|
||||
category: application
|
||||
layer: network
|
||||
tutorials:
|
||||
- https://docs.dapr.io/reference/components-reference/supported-middleware/middleware-opa/
|
||||
code:
|
||||
- https://github.com/dapr/dapr
|
||||
- https://github.com/dapr/components-contrib/blob/master/middleware/http/opa/middleware.go
|
||||
docs_features:
|
||||
go-integration:
|
||||
note: |
|
||||
Dapr's contrib middleware include an OPA integration built on the Go
|
||||
API.
|
||||
[This tutorial](https://docs.dapr.io/reference/components-reference/supported-middleware/middleware-opa/)
|
||||
explains how to configure it.
|
||||
layout: integration-single
|
||||
---
|
||||
Middleware to apply Open Policy Agent policies on incoming requests
|
||||
@@ -0,0 +1,16 @@
|
||||
---
|
||||
title: HTTP API Authorization in Dart
|
||||
labels:
|
||||
layer: network
|
||||
category: application
|
||||
software:
|
||||
- dart
|
||||
tutorials:
|
||||
- https://github.com/adaptant-labs/opa-api-authz-dart/README.md
|
||||
code:
|
||||
- https://github.com/adaptant-labs/opa-api-authz-dart
|
||||
inventors:
|
||||
- adaptant
|
||||
layout: integration-single
|
||||
---
|
||||
This integration demonstrates how to leverage OPA to perform basic HTTP API authorization in a simple Dart microservice. OPA makes it possible to provide fine-grained context-aware authorization for each REST endpoint and access method.
|
||||
@@ -0,0 +1,16 @@
|
||||
---
|
||||
title: Docker controls via OPA Policies
|
||||
software:
|
||||
- docker
|
||||
labels:
|
||||
layer: server
|
||||
category: container
|
||||
code:
|
||||
- https://github.com/open-policy-agent/opa-docker-authz
|
||||
tutorials:
|
||||
- https://www.openpolicyagent.org/docs/latest/docker-authorization/
|
||||
inventors:
|
||||
- styra
|
||||
layout: integration-single
|
||||
---
|
||||
Docker's out of the box authorization model is all or nothing. This integration demonstrates how to use OPA's context-aware policies to exert fine-grained control over Docker.
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
title: Easegress
|
||||
labels:
|
||||
category: gateway
|
||||
layer: network
|
||||
code:
|
||||
- https://github.com/megaease/easegress
|
||||
inventors:
|
||||
- megaease
|
||||
layout: integration-single
|
||||
---
|
||||
Easegress is a Cloud Native API orchestration system.
|
||||
OPA can be configured as a filter(plugin) to implement authorization policies for the APIs.
|
||||
|
||||
@@ -0,0 +1,16 @@
|
||||
---
|
||||
title: Elasticsearch Data Filtering
|
||||
labels:
|
||||
layer: data
|
||||
category: filtering
|
||||
software:
|
||||
- elasticsearch
|
||||
code:
|
||||
- https://github.com/open-policy-agent/contrib/tree/master/data_filter_elasticsearch
|
||||
tutorials:
|
||||
- https://github.com/open-policy-agent/contrib/blob/master/data_filter_elasticsearch/README.md
|
||||
inventors:
|
||||
- styra
|
||||
layout: integration-single
|
||||
---
|
||||
Elasticsearch is a distributed, open source search and analytics engine. This OPA integration lets an elasticsearch client construct queries so that the data returned by elasticsearch obeys OPA-defined policies.
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
title: Emissary-Ingress
|
||||
labels:
|
||||
category: network
|
||||
layer: gateway
|
||||
software:
|
||||
- emissary-ingress
|
||||
blogs:
|
||||
- https://www.infracloud.io/blogs/emissary-ingress-opa-integration/
|
||||
layout: integration-single
|
||||
---
|
||||
Emissary-Ingress is an open-source Kubernetes-native API Gateway, Layer 7 load balancer and Kubernetes Ingress built on Envoy Proxy.
|
||||
OPA can be integrated with Emissary as an external authorization service to enforce authorization policies over APIs.
|
||||
|
||||
@@ -0,0 +1,79 @@
|
||||
---
|
||||
title: Styra Enterprise OPA
|
||||
software:
|
||||
- enterprise-opa
|
||||
labels:
|
||||
category: authorization
|
||||
type: poweredbyopa
|
||||
tutorials:
|
||||
- https://docs.styra.com/enterprise-opa/tutorials
|
||||
- https://docs.styra.com/enterprise-opa/tutorials/performance-testing
|
||||
- https://docs.styra.com/enterprise-opa/tutorials/grpc-basic-tutorial
|
||||
- https://docs.styra.com/enterprise-opa/tutorials/grpc-go-tutorial
|
||||
- https://docs.styra.com/enterprise-opa/tutorials/lia
|
||||
- https://docs.styra.com/enterprise-opa/tutorials/decision-logs/
|
||||
- https://docs.styra.com/enterprise-opa/tutorials/kafka
|
||||
- https://docs.styra.com/enterprise-opa/tutorials/abac-with-sql
|
||||
code:
|
||||
- https://github.com/StyraInc/enterprise-opa
|
||||
inventors:
|
||||
- styra
|
||||
blogs:
|
||||
- https://www.styra.com/blog/introducing-styra-load-enterprise-opa-distribution-for-data-heavy-authorization/
|
||||
videos:
|
||||
- title: Start Loving Your Data-heavy Authorization
|
||||
speakers:
|
||||
- name: Torin Sandall
|
||||
organization: styra
|
||||
- name: Chris Hendrix
|
||||
organization: styra
|
||||
venue: online
|
||||
link: https://www.youtube.com/watch?v=Is1iBPr1YVs
|
||||
docs_features:
|
||||
opa-bundles:
|
||||
note: |
|
||||
Its possible to configure bundles for both
|
||||
[policy](https://docs.styra.com/enterprise-opa/reference/configuration/policy/bundle-api)
|
||||
and
|
||||
[data](https://docs.styra.com/enterprise-opa/reference/configuration/data/bundle-api)
|
||||
in Enterprise OPA.
|
||||
external-data:
|
||||
note: |
|
||||
[Enterprise OPA](https://docs.styra.com/enterprise-opa/)
|
||||
supports various external data sources, including:
|
||||
[Kafka](https://docs.styra.com/enterprise-opa/reference/configuration/data/kafka),
|
||||
[Okta](https://docs.styra.com/enterprise-opa/reference/configuration/data/okta),
|
||||
[LDAP](https://docs.styra.com/enterprise-opa/reference/configuration/data/ldap),
|
||||
[HTTP](https://docs.styra.com/enterprise-opa/reference/configuration/data/http),
|
||||
[Git](https://docs.styra.com/enterprise-opa/reference/configuration/data/git)
|
||||
and
|
||||
[S3](https://docs.styra.com/enterprise-opa/reference/configuration/data/s3).
|
||||
Runtime support for
|
||||
[SQL](https://docs.styra.com/enterprise-opa/tutorials/abac-with-sql)
|
||||
is also available.
|
||||
external-data-runtime:
|
||||
note: |
|
||||
[Enterprise OPA](https://docs.styra.com/enterprise-opa/)
|
||||
can load data from SQL sources at runtime. The feature
|
||||
[is documented](https://docs.styra.com/enterprise-opa/tutorials/abac-with-sql)
|
||||
here with an ABAC example.
|
||||
external-data-realtime-push:
|
||||
note: |
|
||||
It's possible to steam data updates to
|
||||
[Enterprise OPA](https://docs.styra.com/enterprise-opa/)
|
||||
using Kafka. The Kafka integration is
|
||||
[documented](https://docs.styra.com/enterprise-opa/tutorials/kafka)
|
||||
here.
|
||||
policy-testing:
|
||||
note: |
|
||||
[Enterprise OPA's](https://docs.styra.com/enterprise-opa/)
|
||||
[Live Impact Analysis (LIA) feature](https://docs.styra.com/enterprise-opa/tutorials/lia)
|
||||
allows you to test changes to Rego policy on running instances.
|
||||
decision-logging:
|
||||
note: |
|
||||
It's possible to send decision logs to a enterprise tools like Splunk,
|
||||
and Kafka. This enhanced decision logging functionality is
|
||||
[documented here](https://docs.styra.com/enterprise-opa/tutorials/decision-logs/).
|
||||
layout: integration-single
|
||||
---
|
||||
An enterprise-grade drop-in replacement for the Open Policy Agent with improved performance and out of the box enterprise integrations
|
||||
@@ -0,0 +1,59 @@
|
||||
---
|
||||
title: Container Network Authorization with Envoy
|
||||
subtitle: Official OPA Envoy Integration
|
||||
labels:
|
||||
category: servicemesh
|
||||
layer: network
|
||||
software:
|
||||
- envoy
|
||||
tutorials:
|
||||
- https://github.com/tsandall/minimal-opa-envoy-example/blob/master/README.md
|
||||
- https://www.openpolicyagent.org/docs/latest/envoy-introduction/
|
||||
code:
|
||||
- https://github.com/open-policy-agent/opa-envoy-plugin
|
||||
- https://github.com/tsandall/minimal-opa-envoy-example
|
||||
inventors:
|
||||
- styra
|
||||
blogs:
|
||||
- https://blog.openpolicyagent.org/envoy-external-authorization-with-opa-578213ed567c
|
||||
videos:
|
||||
- title: 'OPA at Scale: How Pinterest Manages Policy Distribution'
|
||||
speakers:
|
||||
- name: Will Fu
|
||||
organization: pinterest
|
||||
- name: Jeremy Krach
|
||||
organization: pinterest
|
||||
venue: OPA Summit at Kubecon San Diego 2019
|
||||
link: https://www.youtube.com/watch?v=LhgxFICWsA8
|
||||
- title: Deploying Open Policy Agent at Atlassian
|
||||
speakers:
|
||||
- name: Chris Stivers
|
||||
organization: atlassian
|
||||
- name: Nicholas Higgins
|
||||
organization: atlassian
|
||||
venue: OPA Summit at Kubecon San Diego 2019
|
||||
link: https://www.youtube.com/watch?v=nvRTO8xjmrg
|
||||
- title: How Yelp Moved Security From the App to the Mesh with Envoy and OPA
|
||||
speakers:
|
||||
- name: Daniel Popescu
|
||||
organization: yelp
|
||||
- name: Ben Plotnick
|
||||
organization: yelp
|
||||
venue: Kubecon San Diego 2019
|
||||
link: https://www.youtube.com/watch?v=Z6aN3Smt-9M
|
||||
docs_features:
|
||||
envoy:
|
||||
note: |
|
||||
The
|
||||
[opa-envoy-plugin](https://github.com/open-policy-agent/opa-envoy-plugin)
|
||||
project is the official integration for OPA and Envoy.
|
||||
rest-api-integration:
|
||||
note: |
|
||||
The [opa-envoy-plugin](https://github.com/open-policy-agent/opa-envoy-plugin)
|
||||
project uses the REST API to allow and deny requests routed via an Envoy proxy.
|
||||
|
||||
Read about this integration in the
|
||||
[OPA Docs](https://www.openpolicyagent.org/docs/latest/envoy-introduction/).
|
||||
layout: integration-single
|
||||
---
|
||||
Envoy is a networking abstraction for cloud-native applications. OPA hooks into Envoy’s external authorization filter to provide fine-grained, context-aware authorization for network or HTTP requests.
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
title: Fairwinds Insights Configuration Validation Software
|
||||
labels:
|
||||
category: kubernetes
|
||||
layer: cicd
|
||||
inventors:
|
||||
- fairwinds
|
||||
software:
|
||||
- kubernetes
|
||||
- docker
|
||||
- helm
|
||||
tutorials:
|
||||
- https://insights.docs.fairwinds.com/features/policy/
|
||||
- https://insights.docs.fairwinds.com/reports/opa/
|
||||
- https://insights.docs.fairwinds.com/features/admission-controller/
|
||||
- https://insights.docs.fairwinds.com/features/continuous-integration/
|
||||
videos:
|
||||
- https://youtu.be/kmvPYjx1bpU
|
||||
- https://youtu.be/gxE_Tkj6d40
|
||||
blogs:
|
||||
- https://www.fairwinds.com/blog/managing-opa-policies-with-fairwinds-insights
|
||||
- https://www.fairwinds.com/blog/manage-open-policy-agent-opa-consistently
|
||||
- https://www.fairwinds.com/blog/kubernetes-multi-cluster-visibility-why-how-to-get-it
|
||||
- https://www.fairwinds.com/blog/what-is-kubernetes-policy-as-code
|
||||
- https://www.fairwinds.com/blog/why-kubernetes-policy-enforcement
|
||||
- https://www.fairwinds.com/blog/an-interview-with-flatfile-on-why-fairwinds-insights-kubernetes-configuration-validation
|
||||
docs_features:
|
||||
kubernetes:
|
||||
note: |
|
||||
Implements auditing and admission checking of Kubernetes resources
|
||||
using Rego policy using
|
||||
[Polaris](https://github.com/FairwindsOps/Polaris).
|
||||
layout: integration-single
|
||||
allow_missing_image: true
|
||||
---
|
||||
Automate, monitor and enforce OPA policies with visibility across multiple clusters and multiple teams. It ensures the same policies are applied across all your clusters and gives some flexibility if you want certain policies to apply to only certain workloads. Run the same policies in CI/CD, Admission Control, and In-cluster scanning to apply policy consistently throughout the development and deployment process.
|
||||
@@ -0,0 +1,16 @@
|
||||
---
|
||||
title: fiber
|
||||
labels:
|
||||
category: application
|
||||
layer: library
|
||||
software:
|
||||
- golang
|
||||
- fiber
|
||||
code:
|
||||
- https://github.com/gofiber/contrib/tree/main/opafiber
|
||||
layout: integration-single
|
||||
---
|
||||
Fiber is an Express inspired web framework built on top of Fasthttp, the fastest HTTP engine for Go.
|
||||
Designed to ease things up for fast development with zero memory allocation and performance in mind.
|
||||
With Open Policy Agent integration, you can run your Rego policies as part of the request lifecycle in the middleware.
|
||||
|
||||
@@ -0,0 +1,13 @@
|
||||
---
|
||||
title: fig
|
||||
labels:
|
||||
category: utilities
|
||||
layer: shell
|
||||
code:
|
||||
- https://github.com/open-policy-agent/contrib/tree/main/opa_fig_autocomplete
|
||||
- https://github.com/withfig/autocomplete/blob/master/src/opa.ts
|
||||
inventors:
|
||||
- fig
|
||||
layout: integration-single
|
||||
---
|
||||
Beautiful shell autocompletion for OPA and many other commands, for Mac OS
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
title: Flask-OPA
|
||||
labels:
|
||||
category: flask
|
||||
layer: library
|
||||
software:
|
||||
- flask
|
||||
code:
|
||||
- https://github.com/EliuX/flask-opa
|
||||
blogs:
|
||||
- https://github.com/EliuX/flask-opa/tree/master/examples
|
||||
layout: integration-single
|
||||
---
|
||||
Simple to use Flask extension that lets you secure your projects with OPA. It allows HTTP API Authorization and Policy Enforcement Point (AOP using decorators on methods).
|
||||
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: OPA Gatekeeper
|
||||
subtitle: Rego Policy Controller for Kubernetes
|
||||
labels:
|
||||
type: poweredbyopa
|
||||
layer: configuration
|
||||
code:
|
||||
- https://github.com/open-policy-agent/gatekeeper
|
||||
software:
|
||||
- kubernetes
|
||||
tutorials:
|
||||
- https://open-policy-agent.github.io/gatekeeper/website/docs/howto
|
||||
videos:
|
||||
- https://youtu.be/RMiovzGGCfI?t=1049
|
||||
- https://youtu.be/6RNp3m_THw4?t=864
|
||||
docs_features:
|
||||
go-integration:
|
||||
note: |
|
||||
OPA Gatekeeper is written in Go and uses the
|
||||
[Rego Go API](https://www.openpolicyagent.org/docs/latest/integration/#integrating-with-the-go-api)
|
||||
to evaluate policies loaded from Custom Resources.
|
||||
kubernetes:
|
||||
note: |
|
||||
OPA Gatekeeper integrates with
|
||||
[Kubernetes Admission](https://open-policy-agent.github.io/gatekeeper/website/docs/customize-admission/)
|
||||
and also uses Custom Resources and the Kubernetes API server to
|
||||
store policy state.
|
||||
layout: integration-single
|
||||
allow_missing_image: true
|
||||
---
|
||||
Manage Rego Kubernetes admission policies using Custom Resources.
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: GCP audit with Forseti
|
||||
labels:
|
||||
category: publiccloud
|
||||
inventors:
|
||||
- google
|
||||
code:
|
||||
- https://forsetisecurity.org
|
||||
videos:
|
||||
- title: Repeatable GCP Environments at Scale with Cloud Build Infra-as-Code Pipelines
|
||||
speakers:
|
||||
- name: Morgante Pell
|
||||
organization: google
|
||||
- name: Andrew Phillips
|
||||
organization: google
|
||||
venue: Cloud Next 2019
|
||||
link: https://www.youtube.com/watch?v=3vfXQxWJazM&feature=youtu.be&t=2054
|
||||
layout: integration-single
|
||||
---
|
||||
Google cloud provides a plethora of software as a service.
|
||||
Forseti, built using OPA, lets you run policy checks against the software resources on Google cloud and remediate violations.
|
||||
|
||||
@@ -0,0 +1,13 @@
|
||||
---
|
||||
title: Gloo API Gateway
|
||||
labels:
|
||||
category: servicemesh
|
||||
layer: gateway
|
||||
blogs:
|
||||
- https://medium.com/solo-io/5-min-with-gloo-api-gateway-configuration-with-open-policy-agent-53da276a6534
|
||||
- https://docs.solo.io/gloo/latest/security/auth/opa/
|
||||
layout: integration-single
|
||||
---
|
||||
Gloo is an open-source Kubernetes-native ingress controller, and next-generation API gateway.
|
||||
OPA can be used to implement authorization policies for those APIs.
|
||||
|
||||
@@ -0,0 +1,13 @@
|
||||
---
|
||||
title: Gluu Gateway Authorization
|
||||
labels:
|
||||
layer: network
|
||||
category: gateway
|
||||
software:
|
||||
- gluu
|
||||
- kong
|
||||
code:
|
||||
- https://github.com/GluuFederation/gluu-gateway
|
||||
layout: integration-single
|
||||
---
|
||||
Gluu Gateway provides API authentication and authorization for websites built on Kong. Gluu provides an OPA plugin to handle API authorization.
|
||||
@@ -0,0 +1,16 @@
|
||||
---
|
||||
title: Google Calendar
|
||||
labels:
|
||||
category: data
|
||||
layer: rego
|
||||
software:
|
||||
- google-calendar
|
||||
inventors:
|
||||
- styra
|
||||
code:
|
||||
- https://github.com/anderseknert/opa-google-calendar
|
||||
blogs:
|
||||
- https://blog.styra.com/blog/the-power-of-data-calendar-based-policy-enforcement
|
||||
layout: integration-single
|
||||
---
|
||||
Using the Google Calendar API with OPA for calendar powered policy decisions
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: GKE Policy Automation
|
||||
software:
|
||||
- kubernetes
|
||||
- google-kubernetes-engine
|
||||
labels:
|
||||
category: containers
|
||||
layer: orchestration
|
||||
code:
|
||||
- https://github.com/google/gke-policy-automation
|
||||
tutorials:
|
||||
- https://github.com/google/gke-policy-automation/tree/main/gke-policies
|
||||
inventors:
|
||||
- google
|
||||
docs_features:
|
||||
kubernetes:
|
||||
note: |
|
||||
The GKE Policy Automation project provides a set of policies for
|
||||
validating Kubernetes clusters running on GKE. Review the
|
||||
[policy library here](https://github.com/google/gke-policy-automation/tree/main/gke-policies-v2)
|
||||
layout: integration-single
|
||||
---
|
||||
Tool and policy library for reviewing Google Kubernetes Engine clusters against best practices
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: Gradle Build Plugin
|
||||
labels:
|
||||
layer: cicd
|
||||
category: cicdplugin
|
||||
type: poweredbyopa
|
||||
software:
|
||||
- gradle
|
||||
- java
|
||||
- groovy
|
||||
- kotlin
|
||||
code:
|
||||
- https://github.com/Bisnode/opa-gradle-plugin
|
||||
- https://plugins.gradle.org/plugin/com.bisnode.opa
|
||||
inventors:
|
||||
- bisnode
|
||||
layout: integration-single
|
||||
---
|
||||
Build plugin adding various tasks to support using OPA as part of Gradle builds
|
||||
@@ -0,0 +1,13 @@
|
||||
---
|
||||
title: Custom Application with Field-level Authorization in Graphene GraphQL
|
||||
labels:
|
||||
layer: network
|
||||
category: application
|
||||
software:
|
||||
- graphene-graphql
|
||||
code:
|
||||
- https://github.com/dolevf/graphql-open-policy-agent
|
||||
layout: integration-single
|
||||
---
|
||||
This integration demonstrates using Open Policy Agent to perform field-level Authorization with GraphQL for a custom Python application backed by Graphene.
|
||||
|
||||
@@ -0,0 +1,15 @@
|
||||
---
|
||||
title: GraphQL
|
||||
labels:
|
||||
category: network
|
||||
layer: application
|
||||
software:
|
||||
- graphql
|
||||
code:
|
||||
- https://github.com/StyraInc/graphql-apollo-example
|
||||
tutorials:
|
||||
- https://www.openpolicyagent.org/docs/graphql-api-authorization/
|
||||
layout: integration-single
|
||||
---
|
||||
GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data.
|
||||
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: i2scim.io SCIM Restful User/Group Provisioning API
|
||||
labels:
|
||||
category: security
|
||||
layer: application
|
||||
software:
|
||||
- i2scim
|
||||
code:
|
||||
- https://github.com/i2-open/i2scim
|
||||
- https://i2scim.io
|
||||
inventors:
|
||||
- i2
|
||||
tutorials:
|
||||
- https://i2scim.io/OPA_AccessControl.html
|
||||
docs_features:
|
||||
rest-api-integration:
|
||||
note: |
|
||||
i2scim supports externalized access control decisions using OPA's REST API.
|
||||
The integration is described in the [i2scim documentation](https://i2scim.io/OPA_AccessControl.html).
|
||||
layout: integration-single
|
||||
---
|
||||
i2scim.io is an open source, Apache 2 Licensed, implementation of SCIM (System for Cross-domain Identity Management RFC7643/7644) for use
|
||||
cloud-native kubernetes platforms. i2scim supports externalized access control decisions through OPA. SCIM is a RESTful HTTP API that can be
|
||||
used to provide a standardized way to provision accounts from Azure, Okta, PingIdentity and other providers and tools. SCIM can also be used
|
||||
as a backing identity store for OAuth and other authentication services.
|
||||
|
||||
@@ -0,0 +1,18 @@
|
||||
---
|
||||
title: IPTables
|
||||
labels:
|
||||
layer: network
|
||||
category: linux
|
||||
software:
|
||||
- linux
|
||||
tutorials:
|
||||
- https://github.com/open-policy-agent/contrib/blob/master/opa-iptables/docs/tutorial.md
|
||||
code:
|
||||
- https://github.com/open-policy-agent/contrib/tree/master/opa-iptables
|
||||
inventors:
|
||||
- gsoc
|
||||
- cisco
|
||||
- styra
|
||||
layout: integration-single
|
||||
---
|
||||
IPTables is a useful tool available to Linux kernel for filtering network packets. OPA makes it possible to manage IPTables rules using context-aware policy.
|
||||
@@ -0,0 +1,16 @@
|
||||
---
|
||||
title: Container Network Authorization with Istio (as part of Mixer)
|
||||
labels:
|
||||
category: servicemesh
|
||||
layer: network
|
||||
software:
|
||||
- istio
|
||||
tutorials:
|
||||
- https://istio.io/docs/reference/config/policy-and-telemetry/adapters/opa/
|
||||
code:
|
||||
- https://github.com/istio/istio/tree/master/mixer/adapter/opa
|
||||
inventors:
|
||||
- google
|
||||
layout: integration-single
|
||||
---
|
||||
Istio is a networking abstraction for cloud-native applications. In this Istio integration OPA hooks into the centralized Mixer component of Istio, to provide fine-grained, context-aware authorization for network or HTTP requests.
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
title: Authorization for Java
|
||||
labels:
|
||||
layer: network
|
||||
category: application
|
||||
software:
|
||||
- java
|
||||
code:
|
||||
- https://github.com/Bisnode/opa-java-client
|
||||
inventors:
|
||||
- bisnode
|
||||
layout: integration-single
|
||||
---
|
||||
Integrations for interacting with OPA from Java
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: Jenkins Job Trigger Policy Enforcement
|
||||
labels:
|
||||
layer: cicd
|
||||
software:
|
||||
- jenkins
|
||||
inventors:
|
||||
- pinterest
|
||||
videos:
|
||||
- title: 'OPA at Scale: How Pinterest Manages Policy Distribution'
|
||||
speakers:
|
||||
- name: Will Fu
|
||||
organization: pinterest
|
||||
- name: Jeremy Krach
|
||||
organization: pinterest
|
||||
venue: OPA Summit at Kubecon San Diego 2019
|
||||
link: https://www.youtube.com/watch?v=LhgxFICWsA8
|
||||
layout: integration-single
|
||||
---
|
||||
Jenkins automates software development processes. OPA lets you control which people and which machines can run which Jenkins jobs.
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: Kafka Topic Authorization
|
||||
software:
|
||||
- kafka
|
||||
labels:
|
||||
category: streaming
|
||||
layer: data
|
||||
blogs:
|
||||
- https://opencredo.com/blogs/controlling-kafka-data-flows-using-open-policy-agent/
|
||||
tutorials:
|
||||
- https://www.openpolicyagent.org/docs/latest/kafka-authorization/
|
||||
code:
|
||||
- https://github.com/StyraInc/opa-kafka-plugin
|
||||
- https://github.com/llofberg/kafka-authorizer-opa
|
||||
- https://github.com/opencredo/opa-single-message-transformer
|
||||
inventors:
|
||||
- ticketmaster
|
||||
- styra
|
||||
videos:
|
||||
- title: 'OPA at Scale: How Pinterest Manages Policy Distribution'
|
||||
speakers:
|
||||
- name: Will Fu
|
||||
organization: pinterest
|
||||
- name: Jeremy Krach
|
||||
organization: pinterest
|
||||
venue: OPA Summit at Kubecon San Diego 2019
|
||||
link: https://www.youtube.com/watch?v=LhgxFICWsA8
|
||||
docs_features:
|
||||
rest-api-integration:
|
||||
note: |
|
||||
This project implements a custom
|
||||
[Kafka authorizer](https://docs.confluent.io/platform/current/kafka/authorization.html#authorizer)
|
||||
that uses OPA to make authorization decisions by calling the REST API.
|
||||
|
||||
Installation and configuration instructions are available in the
|
||||
project's [README](https://github.com/StyraInc/opa-kafka-plugin#installation).
|
||||
layout: integration-single
|
||||
---
|
||||
Apache Kafka is a high-performance distributed streaming platform deployed by thousands of companies. OPA provides fine-grained, context-aware access control of which users can read/write which Kafka topics to enforce important requirements around confidentiality and integrity.
|
||||
@@ -0,0 +1,16 @@
|
||||
---
|
||||
title: API Gateway Authorization with Kong
|
||||
labels:
|
||||
layer: network
|
||||
category: gateway
|
||||
software:
|
||||
- kong
|
||||
code:
|
||||
- https://github.com/TravelNest/kong-authorization-opa
|
||||
- https://github.com/open-policy-agent/contrib/tree/master/kong_api_authz
|
||||
inventors:
|
||||
- travelnest
|
||||
- wada-ama
|
||||
layout: integration-single
|
||||
---
|
||||
Kong is a microservice API Gateway. OPA provides fine-grained, context-aware control over the requests that Kong receives.
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
title: Kubernetes Authorization
|
||||
code:
|
||||
- https://github.com/open-policy-agent/contrib/tree/main/k8s_authorization
|
||||
blogs:
|
||||
- https://blog.styra.com/blog/kubernetes-authorization-webhook
|
||||
- https://itnext.io/kubernetes-authorization-via-open-policy-agent-a9455d9d5ceb
|
||||
- https://itnext.io/optimizing-open-policy-agent-based-kubernetes-authorization-via-go-execution-tracer-7b439bb5dc5b
|
||||
inventors:
|
||||
- styra
|
||||
docs_features:
|
||||
rest-api-integration:
|
||||
note: |
|
||||
The Kubernetes API server can be configured to use OPA as an
|
||||
authorization webhook. Such an integration can be configured by
|
||||
following [the documentation](https://github.com/open-policy-agent/contrib/tree/main/k8s_authorization)
|
||||
in the contrib repo.
|
||||
kubernetes:
|
||||
note: |
|
||||
View
|
||||
[an example project](https://github.com/open-policy-agent/contrib/tree/main/k8s_authorization)
|
||||
showing how it's possible to integrate OPA with Kubernetes User Authorization.
|
||||
layout: integration-single
|
||||
---
|
||||
Kubernetes Authorization is a pluggable mechanism that lets administrators control which users can run which APIs and
|
||||
is often handled by builtin RBAC. OPA's policy language is more flexible than the RBAC, for example,
|
||||
writing policy using a prohibited list of APIs instead of the usual RBAC style of listing the permitted APIs.
|
||||
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: Kubernetes Provisioning
|
||||
software:
|
||||
- kubernetes
|
||||
labels:
|
||||
category: containers
|
||||
layer: orchestration
|
||||
inventors:
|
||||
- goldmansachs
|
||||
videos:
|
||||
- title: Kubernetes Policy Enforcement Using OPA at Goldman Sachs
|
||||
speakers:
|
||||
- name: Miguel Uzcategui
|
||||
organization: goldmansachs
|
||||
- name: Tim Hinrichs
|
||||
organization: styra
|
||||
venue: Kubecon San Diego 2019
|
||||
link: https://www.youtube.com/watch?v=lYHr_UaHsYQ&list=PLj6h78yzYM2NDs-iu8WU5fMxINxHXlien&index=140&t=0s
|
||||
layout: integration-single
|
||||
---
|
||||
Kubernetes automates deployment, scaling, and management of containerized applications. OPA decides which resources need to be created on k8s in response to a namespace being created.
|
||||
@@ -0,0 +1,98 @@
|
||||
---
|
||||
title: Kubernetes Admission Control
|
||||
software:
|
||||
- kubernetes
|
||||
labels:
|
||||
category: containers
|
||||
layer: orchestration
|
||||
tutorials:
|
||||
- https://www.openpolicyagent.org/docs/kubernetes-admission-control.html
|
||||
- https://katacoda.com/austinheiman/scenarios/open-policy-agent-gatekeeper
|
||||
code:
|
||||
- https://github.com/open-policy-agent/kube-mgmt
|
||||
- https://github.com/open-policy-agent/gatekeeper
|
||||
inventors:
|
||||
- styra
|
||||
- microsoft
|
||||
- google
|
||||
videos:
|
||||
- title: Securing Kubernetes With Admission Controllers
|
||||
speakers:
|
||||
- name: Dave Strebel
|
||||
organization: microsoft
|
||||
venue: Kubecon Seattle 2018
|
||||
link: https://sched.co/GrZQ
|
||||
- title: Using OPA for Admission Control in Production
|
||||
speakers:
|
||||
- name: Zach Abrahamson
|
||||
organization: Capital One
|
||||
- name: Todd Ekenstam
|
||||
organization: Intuit
|
||||
venue: Kubecon Seattle 2018
|
||||
link: https://sched.co/Grbn
|
||||
- title: Liz Rice Keynote
|
||||
speakers:
|
||||
- name: Liz Rice
|
||||
organization: AquaSecurity
|
||||
venue: Kubecon Seattle 2018
|
||||
link: https://youtu.be/McDzaTnUVWs?t=418
|
||||
- title: Intro to Open Policy Agent Gatekeeper
|
||||
speakers:
|
||||
- name: Rita Zhang
|
||||
organization: microsoft
|
||||
- name: Max Smythe
|
||||
organization: google
|
||||
venue: Kubecon Barcelona 2019
|
||||
link: https://kccnceu19.sched.com/event/MPiM/intro-open-policy-agent-rita-zhang-microsoft-max-smythe-google
|
||||
- title: Policy Enabled Kubernetes and CICD
|
||||
speakers:
|
||||
- name: Jimmy Ray
|
||||
organization: capitalone
|
||||
venue: OPA Summit at Kubecon San Diego 2019
|
||||
link: https://www.youtube.com/watch?v=vkvWZuqSk5M
|
||||
- title: 'TripAdvisor: Building a Testing Framework for Integrating OPA into K8s'
|
||||
speakers:
|
||||
- name: Luke Massa
|
||||
organization: tripadvisor
|
||||
venue: OPA Summit at Kubecon San Diego 2019
|
||||
link: https://www.youtube.com/watch?v=X09c1eXvCFM
|
||||
- title: Enforcing automatic mTLS with Linkerd and OPA Gatekeeper
|
||||
speakers:
|
||||
- name: Ivan Sim
|
||||
organization: buoyant
|
||||
- name: Rita Zhang
|
||||
organization: microsoft
|
||||
venue: Kubecon San Diego 2019
|
||||
link: https://www.youtube.com/watch?v=gMaGVHnvNfs
|
||||
- title: Enforcing Service Mesh Structure using OPA Gatekeeper
|
||||
speakers:
|
||||
- name: Sandeep Parikh
|
||||
organization: google
|
||||
venue: Kubecon San Diego 2019
|
||||
link: https://www.youtube.com/watch?v=90RHTBinAFU
|
||||
- title: 'TGIK: Exploring the Open Policy Agent'
|
||||
speakers:
|
||||
- name: Joe Beda
|
||||
organization: VMware
|
||||
link: https://www.youtube.com/watch?v=QU9BGPf0hBw
|
||||
blogs:
|
||||
- https://medium.com/@sbueringer/kubernetes-authorization-via-open-policy-agent-a9455d9d5ceb
|
||||
- https://medium.com/@jimmy.ray/policy-enabled-kubernetes-with-open-policy-agent-3b612b3f0203
|
||||
- https://blog.openpolicyagent.org/securing-the-kubernetes-api-with-open-policy-agent-ce93af0552c3
|
||||
- https://itnext.io/kubernetes-authorization-via-open-policy-agent-a9455d9d5ceb
|
||||
- https://medium.com/capital-one-tech/policy-enabled-kubernetes-with-open-policy-agent-3b612b3f0203
|
||||
- https://blog.openshift.com/fine-grained-policy-enforcement-in-openshift-with-open-policy-agent/
|
||||
docs_features:
|
||||
rest-api-integration:
|
||||
note: |
|
||||
The Kubernetes API server can be configured to use OPA as an
|
||||
admission controller. Creating a
|
||||
[ValidatingWebhookConfiguration](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#validatingwebhookconfiguration)
|
||||
resource can be used to query OPA for policy decisions.
|
||||
kubernetes:
|
||||
note: |
|
||||
View a selection of projects and talks about integrating OPA with
|
||||
Kubernetes.
|
||||
layout: integration-single
|
||||
---
|
||||
Kubernetes automates deployment, scaling, and management of containerized applications. OPA provides fine-grained, context-aware authorization for which application component configuration.
|
||||
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: Kubescape
|
||||
subtitle: Kubernetes security posture scanner
|
||||
labels:
|
||||
category: security
|
||||
layer: application
|
||||
software:
|
||||
- kubescape
|
||||
code:
|
||||
- https://github.com/kubescape/kubescape
|
||||
- https://github.com/kubescape/regolibrary
|
||||
inventors:
|
||||
- armo
|
||||
tutorials:
|
||||
- https://hub.armosec.io/docs
|
||||
docs_features:
|
||||
go-integration:
|
||||
note: |
|
||||
Kubescape uses the Go Repo API to test Kubernetes objects against
|
||||
a range of posture controls.
|
||||
layout: integration-single
|
||||
---
|
||||
This integration uses OPA for defining security controls over Kubernetes clusters. Kubescape is a simple extensible tool
|
||||
finding security problems in your environment. OPA enables Kubescape to implement and extend very fast to answer new problems.
|
||||
|
||||
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: KubeShield
|
||||
subtitle: Secure Kubernetes using eBPF & Open Policy Agent
|
||||
software:
|
||||
- linux
|
||||
- kubernetes
|
||||
- ebpf
|
||||
labels:
|
||||
layer: application
|
||||
category: filtering
|
||||
code:
|
||||
- https://github.com/kubeshield/bpf-opa-demo
|
||||
blogs:
|
||||
- https://blog.byte.builders/post/bpf-opa/
|
||||
docs_features:
|
||||
kubernetes:
|
||||
note: |
|
||||
KubeShield implements runtime policy for containers in a Kubernetes
|
||||
cluster using eBPF. Follow the
|
||||
[tutorial here](https://github.com/kubeshield/bpf-opa-demo#usage)
|
||||
to get up and running.
|
||||
layout: integration-single
|
||||
---
|
||||
Ensure runtime security in any linux machine by combining Extended Berkeley Packet Filter(eBPF) and Open Policy Agent.
|
||||
@@ -0,0 +1,15 @@
|
||||
---
|
||||
title: SSH and Sudo Authorization with Linux
|
||||
software:
|
||||
- linuxpam
|
||||
labels:
|
||||
layer: server
|
||||
tutorials:
|
||||
- https://www.openpolicyagent.org/docs/ssh-and-sudo-authorization.html
|
||||
code:
|
||||
- https://github.com/open-policy-agent/contrib/tree/master/pam_opa
|
||||
inventors:
|
||||
- styra
|
||||
layout: integration-single
|
||||
---
|
||||
Host-level access controls are an important part of every organization's security strategy. OPA provides fine-grained, context-aware controls for SSH and sudo using Linux-PAM.
|
||||
@@ -0,0 +1,18 @@
|
||||
---
|
||||
title: Magda
|
||||
labels:
|
||||
type: poweredbyopa
|
||||
category: application
|
||||
layer: application
|
||||
software:
|
||||
- magda
|
||||
code:
|
||||
- https://github.com/magda-io/magda
|
||||
blogs:
|
||||
- https://github.com/magda-io/magda/blob/master/docs/docs/architecture/Guide%20to%20Magda%20Internals.md#authorization-authz
|
||||
layout: integration-single
|
||||
---
|
||||
Magda is a federated, Kubernetes-based, open-source data catalog system.
|
||||
Working as Magda's central authorisation policy engine, OPA helps not only the API endpoint authorisation.
|
||||
Magda also uses its partial evaluation feature to translate datasets authorisation decisions to other database-specific DSLs (e.g. SQL or Elasticsearch DSL) and use them for dataset authorisation enforcement in different databases.
|
||||
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: Minio API Authorization
|
||||
labels:
|
||||
layer: data
|
||||
category: authorization
|
||||
tutorials:
|
||||
- https://github.com/minio/minio/blob/master/docs/iam/opa.md
|
||||
inventors:
|
||||
- minio
|
||||
- styra
|
||||
docs_features:
|
||||
rest-api-integration:
|
||||
note: |
|
||||
Minio implements a native integration with OPA using the REST API.
|
||||
The [integration is documented](https://github.com/minio/minio/blob/master/docs/iam/opa.md)
|
||||
in the Minio docs.
|
||||
layout: integration-single
|
||||
---
|
||||
Minio is an open source, on-premise object database compatible with the Amazon S3 API. This integration lets OPA enforce policies on Minio's API.
|
||||
@@ -0,0 +1,12 @@
|
||||
---
|
||||
title: Nginx
|
||||
labels:
|
||||
category: gateway
|
||||
layer: network
|
||||
software:
|
||||
- nginx
|
||||
code:
|
||||
- https://github.com/summerwind/opa-nginx-rbac
|
||||
layout: integration-single
|
||||
---
|
||||
OPA Authorization for Nginx
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: NodeJS express
|
||||
labels:
|
||||
category: application
|
||||
layer: network
|
||||
code:
|
||||
- https://github.com/build-security/opa-express-middleware
|
||||
inventors:
|
||||
- build.security
|
||||
software:
|
||||
- nodejsexpress
|
||||
docs_features:
|
||||
rest-api-integration:
|
||||
note: |
|
||||
This project provides a middleware that can query an OPA server for
|
||||
policy decisions. See the project's
|
||||
[README](https://github.com/build-security/opa-express-middleware#simple-usage)
|
||||
for a js simple example.
|
||||
layout: integration-single
|
||||
---
|
||||
Express is a minimal and flexible Node.js web application framework that provides a robust set of features for web and mobile applications.
|
||||
OPA can be used to implement authorization policies for APIs used in the express framework.
|
||||
|
||||
@@ -0,0 +1,13 @@
|
||||
---
|
||||
title: OAuth2
|
||||
software:
|
||||
- oauth
|
||||
labels:
|
||||
category: security
|
||||
tutorials:
|
||||
- https://www.openpolicyagent.org/docs/latest/oauth-oidc/
|
||||
blogs:
|
||||
- https://blog.styra.com/blog/integrating-identity-oauth2-and-openid-connect-in-open-policy-agent
|
||||
layout: integration-single
|
||||
---
|
||||
Integrating OAuth2 with Open Policy Agent
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
title: OpenID Connect (OIDC)
|
||||
software:
|
||||
- oauth
|
||||
- oidc
|
||||
labels:
|
||||
category: security
|
||||
tutorials:
|
||||
- https://www.openpolicyagent.org/docs/latest/oauth-oidc/
|
||||
blogs:
|
||||
- https://blog.styra.com/blog/integrating-identity-oauth2-and-openid-connect-in-open-policy-agent
|
||||
layout: integration-single
|
||||
---
|
||||
Integrating OpenID Connect (OIDC) with Open Policy Agent
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: OPA Playground
|
||||
subtitle: Online Rego Playground
|
||||
software: []
|
||||
inventors:
|
||||
- styra
|
||||
labels:
|
||||
category: tooling
|
||||
layer: rego
|
||||
code:
|
||||
- https://play.openpolicyagent.org/
|
||||
blogs:
|
||||
- https://blog.openpolicyagent.org/the-rego-playground-977566855cec
|
||||
- https://blog.openpolicyagent.org/rego-playground-new-features-ec0345a73b9e
|
||||
docs_features:
|
||||
learning-rego:
|
||||
note: |
|
||||
Sometimes if you're working on a Rego policy in an integrated system
|
||||
it can help to debug it in isolation first. The playground is a great
|
||||
place to do that. Get started with a [hello world example](https://play.openpolicyagent.org/).
|
||||
language-tooling:
|
||||
note: |
|
||||
The playground is a great place to get started with writing and testing
|
||||
your first policies. You can also share links if you're asking for
|
||||
help in the community Slack. Get started with a simple
|
||||
[RBAC example](https://play.openpolicyagent.org/p/Bb9FqBvauC).
|
||||
layout: integration-single
|
||||
---
|
||||
Interactive online Rego playground for writing and sharing policies
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: OPA Wasm .NET package
|
||||
software:
|
||||
- csharp
|
||||
inventors:
|
||||
- christophwille
|
||||
labels:
|
||||
category: wasm
|
||||
type: poweredbyopa
|
||||
tutorials:
|
||||
- https://github.com/christophwille/dotnet-opa-wasm
|
||||
code:
|
||||
- https://github.com/christophwille/dotnet-opa-wasm
|
||||
- https://www.nuget.org/packages/Opa.Wasm/
|
||||
docs_features:
|
||||
wasm-integration:
|
||||
note: 'This project implements the OPA Wasm module interface in C#.
|
||||
|
||||
'
|
||||
layout: integration-single
|
||||
---
|
||||
Call Rego policies in Wasm from C# .NET Core
|
||||
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: OPA Wasm Java Gradle SDK
|
||||
software:
|
||||
- java
|
||||
inventors:
|
||||
- sangkeon
|
||||
labels:
|
||||
category: wasm
|
||||
type: poweredbyopa
|
||||
tutorials:
|
||||
- https://github.com/sangkeon/java-opa-wasm#usage
|
||||
code:
|
||||
- https://github.com/sangkeon/java-opa-wasm
|
||||
docs_features:
|
||||
wasm-integration:
|
||||
note: 'This project implements the OPA Wasm module interface in Java.
|
||||
|
||||
'
|
||||
layout: integration-single
|
||||
---
|
||||
SDK to illustrate how to use Wasm compiled Rego policies from a Java application
|
||||
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: OPA Wasm Javascript Module
|
||||
software:
|
||||
- javascript
|
||||
inventors:
|
||||
- styra
|
||||
labels:
|
||||
category: wasm
|
||||
type: poweredbyopa
|
||||
tutorials:
|
||||
- https://github.com/open-policy-agent/npm-opa-wasm/blob/main/README.md
|
||||
code:
|
||||
- https://github.com/open-policy-agent/npm-opa-wasm/
|
||||
- https://www.npmjs.com/package/@open-policy-agent/opa-wasm?activeTab=readme
|
||||
videos:
|
||||
- title: 'Scratching an Itch: Running Policy in Hard to Reach Places with Wasm & OPA'
|
||||
speakers:
|
||||
- name: Charlie Egan
|
||||
organization: styra
|
||||
link: https://www.youtube.com/watch?v=BdeBhukLwt4
|
||||
docs_features:
|
||||
wasm-integration:
|
||||
note: 'This project implements the OPA Wasm module interface in JavaScript.
|
||||
|
||||
'
|
||||
layout: integration-single
|
||||
---
|
||||
A small SDK for using WebAssembly (Wasm) compiled Rego policies
|
||||
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: OPA Wasm Rust Crate
|
||||
software:
|
||||
- rust
|
||||
inventors:
|
||||
- matrix
|
||||
labels:
|
||||
category: wasm
|
||||
type: poweredbyopa
|
||||
tutorials:
|
||||
- https://github.com/matrix-org/rust-opa-wasm#try-it-out
|
||||
- https://docs.rs/opa/latest/opa/wasm/index.html
|
||||
code:
|
||||
- https://github.com/matrix-org/rust-opa-wasm
|
||||
docs_features:
|
||||
wasm-integration:
|
||||
note: 'This project implements the OPA Wasm module interface in Rust.
|
||||
|
||||
'
|
||||
layout: integration-single
|
||||
---
|
||||
A crate to use OPA policies compiled to WASM.
|
||||
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
title: OPAL
|
||||
subtitle: Open Policy Administration Layer
|
||||
labels:
|
||||
category: updates
|
||||
layer: application
|
||||
inventors:
|
||||
- permitio
|
||||
software:
|
||||
- opal
|
||||
code:
|
||||
- https://github.com/permitio/opal
|
||||
tutorials:
|
||||
- https://github.com/permitio/opal/tree/master/documentation/docs/tutorials
|
||||
videos:
|
||||
- https://www.youtube.com/watch?v=K1Zm2FPfrh8
|
||||
docs_features:
|
||||
rest-api-integration:
|
||||
note: |
|
||||
OPAL uses the OPA REST API to update the policy and data pushed down
|
||||
from the OPAL server.
|
||||
See [how this works](https://docs.opal.ac/overview/architecture).
|
||||
external-data:
|
||||
note: |
|
||||
The OPAL Client uses the OPA REST API to update the state pushed down
|
||||
from the OPAL server.
|
||||
See [how this works](https://docs.opal.ac/overview/architecture).
|
||||
external-data-realtime-push:
|
||||
note: |
|
||||
OPAL is able to deliver real-time data updates to OPA instances.
|
||||
See
|
||||
[how this works](https://docs.opal.ac/getting-started/quickstart/opal-playground/publishing-data-update)
|
||||
in the OPAL docs.
|
||||
layout: integration-single
|
||||
---
|
||||
OPAL is an administration layer for Open Policy Agent (OPA), detecting changes in realtime to both policy and policy data and pushing live updates to your agents.
|
||||
OPAL brings open-policy up to the speed needed by live applications. As your application state changes (whether it's via your APIs, DBs, git, S3 or 3rd-party SaaS services), OPAL will make sure your services are always in sync with the authorization data and policy they need (and only those they need).
|
||||
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
title: Open Policy Registry
|
||||
subtitle: A Docker-inspired workflow for OPA policies
|
||||
labels:
|
||||
category: containers
|
||||
layer: application
|
||||
inventors:
|
||||
- aserto
|
||||
software:
|
||||
- open-policy-registry
|
||||
code:
|
||||
- https://github.com/opcr-io/policy
|
||||
tutorials:
|
||||
- https://www.openpolicyregistry.io/docs/tutorial
|
||||
blogs:
|
||||
- https://www.openpolicyregistry.io/blog/docker-workflow-for-opa
|
||||
docs_features:
|
||||
go-integration:
|
||||
note: |
|
||||
Makes use of the
|
||||
[OPA Repl package](https://pkg.go.dev/github.com/open-policy-agent/opa/repl)
|
||||
to interact with an OPA instance.
|
||||
opa-bundles:
|
||||
note: |
|
||||
OPCR policy images can be loaded in over the Bundle API. The feature
|
||||
it documented in the
|
||||
[OPCR docs](https://openpolicycontainers.com/docs/opa).
|
||||
opa-bundles-discovery:
|
||||
note: |
|
||||
OPCR images can be loaded in over the Bundle API and contain
|
||||
discovery bundles. The feature it documented in the
|
||||
[OPCR docs](https://openpolicycontainers.com/docs/opa).
|
||||
external-data:
|
||||
note: |
|
||||
OPCR policy images can contain data as well as policy. If you need to
|
||||
distribute data to OPA from an OCI registry, OPCR can build and push
|
||||
such images. See the docs for
|
||||
[building images here](https://openpolicycontainers.com/docs/cli/build).
|
||||
layout: integration-single
|
||||
---
|
||||
The Open Policy Registry project provides a docker-style workflow for OPA policies.
|
||||
The policy CLI can be used to build, tag, sign, push, and pull OPA policies as OCIv2 container images,
|
||||
in conjunction with any container registry.
|
||||
The Open Policy Registry (OPCR) is a reference implementation of a policy registry, built and hosted on GCP.
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
---
|
||||
title: Open Service Mesh (OSM)
|
||||
software:
|
||||
- osm
|
||||
labels:
|
||||
category: servicemesh
|
||||
layer: network
|
||||
tutorials:
|
||||
- https://release-v1-2.docs.openservicemesh.io/docs/guides/integrations/external_auth_opa/
|
||||
docs_features:
|
||||
envoy:
|
||||
note: |
|
||||
External Authorization supports OPA and is documented
|
||||
[here](https://release-v1-2.docs.openservicemesh.io/docs/guides/integrations/external_auth_opa/)
|
||||
layout: integration-single
|
||||
---
|
||||
Open Service Mesh is a lightweight and extensible cloud native service mesh.
|
||||
@@ -0,0 +1,16 @@
|
||||
---
|
||||
title: OpenFaaS Serverless Function Authorization
|
||||
labels:
|
||||
layer: application
|
||||
category: serverless
|
||||
software:
|
||||
- openfaas
|
||||
code:
|
||||
- https://github.com/adaptant-labs/openfaas-function-auth-opa
|
||||
tutorials:
|
||||
- https://github.com/adaptant-labs/openfaas-function-auth-opa/blob/master/README.md
|
||||
inventors:
|
||||
- adaptant
|
||||
layout: integration-single
|
||||
---
|
||||
OpenFaaS is a serverless function framework that runs on Docker Swarm and Kubernetes. OPA makes it possible to provide fine-grained context-aware authorization on a per-function basis.
|
||||
@@ -0,0 +1,17 @@
|
||||
---
|
||||
title: OPToggles (Open Policy Toggles)
|
||||
labels:
|
||||
category: updates
|
||||
layer: application
|
||||
inventors:
|
||||
- permitio
|
||||
code:
|
||||
- https://github.com/permitio/OPToggles
|
||||
tutorials:
|
||||
- https://optoggles.opal.ac/tutorials/demo
|
||||
layout: integration-single
|
||||
---
|
||||
OPToggles uses OPA and OPAL to sync open-policy to your frontend with the help of feature flag solutions.
|
||||
OPToggles creates user-targeted feature flags based on the policy rules you defined in OPA and keeps the users updated in real-time with OPAL's real-time policy and policy-data change detection.
|
||||
OPToggles already supports launchdarkly.com and a generic REST API.
|
||||
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: Permit.io
|
||||
labels:
|
||||
category: authorization
|
||||
layer: application
|
||||
inventors:
|
||||
- permitio
|
||||
code:
|
||||
- https://github.com/permitio
|
||||
tutorials:
|
||||
- https://docs.permit.io/
|
||||
videos:
|
||||
- https://docs.permit.io/tutorials/onboarding_demo
|
||||
blogs:
|
||||
- https://www.permit.io/blog/introduction-to-opa
|
||||
- https://www.permit.io/blog/implement-abac-using-opa
|
||||
- https://www.permit.io/blog/implement-rbac-using-opa
|
||||
layout: integration-single
|
||||
---
|
||||
Permit.io empowers developers to bake in permissions and access-control into any product in minutes and takes away the pain of constantly rebuilding them.
|
||||
Permit is based on OPA.
|
||||
|
||||
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: PHP OPA Library
|
||||
labels:
|
||||
layer: network
|
||||
category: application
|
||||
software:
|
||||
- php
|
||||
tutorials:
|
||||
- https://coil.com/p/segra/OPA-for-API-Authorization-with-Slim-PHP/H-7YsQL2m
|
||||
code:
|
||||
- https://github.com/segrax/opa-php-examples
|
||||
- https://github.com/segrax/openpolicyagent
|
||||
- https://github.com/build-security/opa-symfony-middleware
|
||||
inventors:
|
||||
- build.security
|
||||
docs_features:
|
||||
rest-api-integration:
|
||||
note: |
|
||||
This library provides a PHP wrapper around the OPA REST API. It can
|
||||
update policies and query for decisions. See the
|
||||
[project README](https://github.com/segrax/openpolicyagent)
|
||||
for various examples.
|
||||
layout: integration-single
|
||||
---
|
||||
These integrations demonstrate using OPA to perform API authorization in PSR-15 and Symfony compliant frameworks.
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
title: Pomerium Access Proxy
|
||||
labels:
|
||||
layer: network
|
||||
category: proxy
|
||||
software:
|
||||
- pomerium
|
||||
blogs:
|
||||
- https://www.pomerium.io/posts/2020/04/16/release-0-7/
|
||||
code:
|
||||
- https://github.com/pomerium/pomerium
|
||||
layout: integration-single
|
||||
---
|
||||
Pomerium is an identity-aware proxy that enables secure access to internal applications. OPA implements authorization under the hood.
|
||||
@@ -0,0 +1,17 @@
|
||||
---
|
||||
title: Pre-commit hooks
|
||||
labels:
|
||||
category: tooling
|
||||
layer: cicd
|
||||
software:
|
||||
- git
|
||||
- pre-commit
|
||||
code:
|
||||
- https://github.com/anderseknert/pre-commit-opa
|
||||
blogs:
|
||||
- https://www.eknert.com/tech/2020/08/31/pre-commit-hooks-for-opa
|
||||
inventors:
|
||||
- independent
|
||||
layout: integration-single
|
||||
---
|
||||
Pre-commit git hooks for OPA and Rego development
|
||||
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: Pulumi
|
||||
software:
|
||||
- pulumi
|
||||
- aws
|
||||
- gcp
|
||||
- azure
|
||||
labels:
|
||||
category: publiccloud
|
||||
layer: orchestration
|
||||
code:
|
||||
- https://github.com/pulumi/pulumi-policy-opa
|
||||
blogs:
|
||||
- https://www.pulumi.com/blog/opa-support-for-crossguard/
|
||||
videos:
|
||||
- title: Testing Configuration with Open Policy Agent
|
||||
speakers:
|
||||
- name: Gareth Rushgrove
|
||||
organization: snyk
|
||||
venue: Cloud Engineering Summit 2020
|
||||
link: https://www.pulumi.com/resources/testing-configuration-with-open-policy-agent/
|
||||
inventors:
|
||||
- pulumi
|
||||
docs_features:
|
||||
go-integration:
|
||||
note: |
|
||||
The Pulumi OPA bridge uses the Rego API to evaluate policies in a
|
||||
policy pack. View the [docs and code](https://github.com/pulumi/pulumi-policy-opa).
|
||||
layout: integration-single
|
||||
---
|
||||
Build infrastructure as code in familiar languages. CrossGuard is Pulumi's policy as code offering, providing OPA as one of the options to use for defining policy.
|
||||
@@ -0,0 +1,44 @@
|
||||
---
|
||||
title: Regal
|
||||
subtitle: The Linter of Rego Language
|
||||
labels:
|
||||
category: tooling
|
||||
layer: shell
|
||||
inventors:
|
||||
- styra
|
||||
blogs:
|
||||
- https://www.styra.com/blog/guarding-the-guardrails-introducing-regal-the-rego-linter/
|
||||
code:
|
||||
- https://github.com/StyraInc/regal
|
||||
videos:
|
||||
- https://www.youtube.com/live/Xx8npd2TQJ0?feature=share&t=2567
|
||||
tutorials:
|
||||
- https://github.com/StyraInc/regal#try-it-out
|
||||
docs_features:
|
||||
learning-rego:
|
||||
note: |
|
||||
Regal can automatically check for common Rego mistakes as you code.
|
||||
Each violation is accompanied by a detailed explanation which can be a
|
||||
great learning tool for new Rego users. See the
|
||||
[Supported Rules](https://github.com/StyraInc/regal/tree/main#rules).
|
||||
go-integration:
|
||||
note: |
|
||||
Regal is built using the Go Rego API. Regal evaluates linting rules
|
||||
defined in Rego against the Rego AST of policy files. The
|
||||
[linter package](https://github.com/StyraInc/regal/blob/main/pkg/linter/linter.go)
|
||||
is a good place to see how OPA is used in the project.
|
||||
policy-testing:
|
||||
note: |
|
||||
Regal is a useful step to use when testing Rego policies to ensure
|
||||
code is correct and free of common errors. See
|
||||
[the README](https://github.com/StyraInc/regal#try-it-out)
|
||||
to get started.
|
||||
layout: integration-single
|
||||
---
|
||||
Regal is a linter for Rego, with the goal of making your Rego magnificent!
|
||||
|
||||
Regal can:
|
||||
* Identify common mistakes, bugs and inefficiencies in Rego policies, and suggest better approaches
|
||||
* Provide advice on best practices, coding style, and tooling
|
||||
* Allow users, teams and organizations to enforce custom rules on their policy code
|
||||
|
||||
@@ -0,0 +1,18 @@
|
||||
---
|
||||
title: Rekor transparency log monitoring and alerting
|
||||
labels:
|
||||
category: security
|
||||
layer: application
|
||||
software:
|
||||
- rekor
|
||||
inventors:
|
||||
- sigstore
|
||||
code:
|
||||
- https://github.com/nsmith5/rekor-sidekick
|
||||
videos:
|
||||
- https://www.youtube.com/watch?v=lHSLPIo1pz8
|
||||
layout: integration-single
|
||||
---
|
||||
Rekor Sidekick monitors a Rekor signature transparency log and forwards events of interest where ever you like.
|
||||
Alert policies written in Rego determine if an event is of interest.
|
||||
|
||||
@@ -0,0 +1,16 @@
|
||||
---
|
||||
title: Reposaur
|
||||
software:
|
||||
- github
|
||||
labels:
|
||||
category: security
|
||||
type: poweredbyopa
|
||||
tutorials:
|
||||
- https://docs.reposaur.com/guides/writing-your-first-policy
|
||||
code:
|
||||
- https://github.com/reposaur/reposaur
|
||||
inventors:
|
||||
- reposaur
|
||||
layout: integration-single
|
||||
---
|
||||
Audit, verify and report on development platforms (GitHub and others) easily with pre-defined and/or custom policies.
|
||||
@@ -0,0 +1,34 @@
|
||||
---
|
||||
title: Rönd
|
||||
software:
|
||||
- rond
|
||||
labels:
|
||||
category: authorization
|
||||
layer: application
|
||||
code:
|
||||
- https://github.com/rond-authz/rond
|
||||
tutorials:
|
||||
- https://github.com/rond-authz/example
|
||||
videos:
|
||||
- title: Rönd - The Open Source K8s sidecar that defines security policies over your
|
||||
APIs
|
||||
speakers:
|
||||
- name: Federico Maggi
|
||||
organization: mia-platform
|
||||
link: https://youtu.be/ubT31NtHV8w
|
||||
inventors:
|
||||
- mia-platform
|
||||
blogs:
|
||||
- https://blog.mia-platform.eu/en/announcing-rond-new-open-source-security-enforcement-over-your-apis
|
||||
- https://blog.mia-platform.eu/en/how-why-adopted-role-based-access-control-rbac
|
||||
docs_features:
|
||||
go-integration:
|
||||
note: |
|
||||
The Rönd sidecar uses the OPA Rego API to make API-access
|
||||
authorization decisions. See the
|
||||
[OPA evaluator](https://github.com/rond-authz/rond/blob/4c27fa6a127f68b8670a39c792b0e40dac52dafa/core/opaevaluator.go#L173)
|
||||
code.
|
||||
layout: integration-single
|
||||
---
|
||||
Rönd is a lightweight container that distributes security policy enforcement throughout your application.
|
||||
|
||||
@@ -0,0 +1,18 @@
|
||||
---
|
||||
title: Sansshell
|
||||
software:
|
||||
- sansshell
|
||||
labels:
|
||||
category: management
|
||||
layer: server
|
||||
type: poweredbyopa
|
||||
code:
|
||||
- https://github.com/Snowflake-Labs/sansshell
|
||||
blogs:
|
||||
- https://www.snowflake.com/blog/sansshell-local-host-agent/
|
||||
inventors:
|
||||
- snowflake
|
||||
layout: integration-single
|
||||
allow_missing_image: true
|
||||
---
|
||||
A non-interactive daemon for host management
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
title: Scalr
|
||||
subtitle: Policy enforcement for Terraform
|
||||
labels:
|
||||
category: Infrastructure as Code
|
||||
layer: cicd
|
||||
software:
|
||||
- terraform
|
||||
tutorials:
|
||||
- https://iacp.docs.scalr.com/en/latest/working-with-iacp/opa.html#creating-the-opa-policy
|
||||
code:
|
||||
- https://github.com/Scalr/sample-tf-opa-policies
|
||||
inventors:
|
||||
- scalr
|
||||
blogs:
|
||||
- https://www.scalr.com/blog/opa-is-to-policy-automation-as-terraform-is-to-iac/
|
||||
docs_features:
|
||||
cli-integration:
|
||||
note: |
|
||||
These policies can be run using OPA at the command line against a
|
||||
Terraform plan JSON. See
|
||||
[the example](https://github.com/Scalr/sample-tf-opa-policies#policy-evaluation)
|
||||
in the README.
|
||||
terraform:
|
||||
note: |
|
||||
These policies can be run using OPA at the command line against a
|
||||
Terraform plan JSON. See
|
||||
[the example](https://github.com/Scalr/sample-tf-opa-policies#policy-evaluation)
|
||||
in the README.
|
||||
layout: integration-single
|
||||
---
|
||||
Scalr allows teams to easily collaborate on Terraform through its pipeline that runs all Terraform operations, policy checks, and stores state. Scalr uses OPA to check the auto-generated Terraform JSON plan to ensure that it meets your organization standards prior to an apply.
|
||||
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: Spacelift
|
||||
labels:
|
||||
category: Infrastructure as Code
|
||||
layer: cicd
|
||||
software:
|
||||
- terraform
|
||||
- pulumi
|
||||
- cloudformation
|
||||
- kubernetes
|
||||
- ansible
|
||||
- aws
|
||||
- gcp
|
||||
- azure
|
||||
tutorials:
|
||||
- https://docs.spacelift.io/concepts/policy
|
||||
code:
|
||||
- https://github.com/spacelift-io/spacelift-policies-example-library
|
||||
inventors:
|
||||
- spacelift
|
||||
blogs:
|
||||
- https://spacelift.io/blog/what-is-open-policy-agent-and-how-it-works
|
||||
docs_features:
|
||||
rego-language-embedding:
|
||||
note: |
|
||||
Spacelift supports Rego as a language to describe policies for IaC
|
||||
resources. View the docs on
|
||||
[creating Rego policies](https://docs.spacelift.io/concepts/policy/).
|
||||
terraform:
|
||||
note: |
|
||||
Spacelift supports Rego as a language to describe policies for Terraform
|
||||
JSON plans.
|
||||
[This blog](https://spacelift.io/blog/what-is-open-policy-agent-and-how-it-works)
|
||||
outlines how the integration works.
|
||||
kubernetes:
|
||||
note: |
|
||||
Spacelift supports Rego as a language to describe policies for various
|
||||
resource types, including Kubernetes. View the
|
||||
[policy documentation](https://docs.spacelift.io/concepts/policy/) for
|
||||
more information.
|
||||
layout: integration-single
|
||||
---
|
||||
Spacelift is a sophisticated CI/CD platform for Infrastructure as Code including Terraform, Pulumi, CloudFormation, Kubernetes, and Ansible. Spacelift utilizes Open Policy Agent to support a variety of policy types within the platform and Policy as Code for secure and compliance Infrastructure as Code.
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
title: Automatically document Rego policies
|
||||
software:
|
||||
- sphinx-doc
|
||||
code:
|
||||
- https://github.com/zenitysec/sphinx-rego
|
||||
inventors:
|
||||
- zenity
|
||||
labels:
|
||||
category: tooling
|
||||
layer: cicd
|
||||
layout: integration-single
|
||||
---
|
||||
Sphinx extension that automatically documents Open Policy Agent Rego policies using meta properties.
|
||||
@@ -0,0 +1,15 @@
|
||||
---
|
||||
title: Spinnaker Pipeline Policy Enforcment
|
||||
labels:
|
||||
layer: cicd
|
||||
software:
|
||||
- spinnaker
|
||||
blogs:
|
||||
- https://blog.armory.io/deployment-policies-with-spinnaker/
|
||||
tutorials:
|
||||
- https://docs.armory.io/spinnaker/policy_engine/
|
||||
inventors:
|
||||
- armory
|
||||
layout: integration-single
|
||||
---
|
||||
Spinnaker is a Continuous Delivery and Deployment tool started by Netflix. OPA lets you configure policies that dictate what kinds of Spinnaker pipelines developers can create.
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: SPIRE
|
||||
labels:
|
||||
layer: network
|
||||
category: application
|
||||
software:
|
||||
- spiffe
|
||||
- spire
|
||||
blogs:
|
||||
- https://www.styra.com/blog/zero-trust-with-envoy-spire-and-open-policy-agent-opa/
|
||||
code:
|
||||
- https://github.com/spiffe/spire/blob/v1.0.2/doc/authorization_policy_engine.md
|
||||
tutorials:
|
||||
- https://spiffe.io/docs/latest/microservices/envoy-opa/readme/
|
||||
- https://spiffe.io/docs/latest/microservices/envoy-jwt-opa/readme/
|
||||
docs_features:
|
||||
envoy:
|
||||
note: |
|
||||
SPIRE can be used to integrate with Envoy and OPA. See a
|
||||
[blog here](https://www.styra.com/blog/zero-trust-with-envoy-spire-and-open-policy-agent-opa/)
|
||||
to learn more.
|
||||
rest-api-integration:
|
||||
note: |
|
||||
SPIRE can work in tandem with the Envoy proxy to integrate with the OPA
|
||||
REST API. See the
|
||||
[tutorial here](https://spiffe.io/docs/latest/microservices/envoy-jwt-opa/readme/).
|
||||
layout: integration-single
|
||||
---
|
||||
SPIRE is a production-ready implementation of the SPIFFE APIs that performs node and workload attestation in order to securely issue SPIFFE Verifiable Identity Documents (SVIDs) to workloads, and verify the SVIDs of other workloads, based on a predefined set of conditions.
|
||||
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: Authorization for Java Spring Security
|
||||
labels:
|
||||
layer: network
|
||||
category: application
|
||||
software:
|
||||
- javaspringsecurity
|
||||
code:
|
||||
- https://github.com/open-policy-agent/contrib/tree/master/spring_authz
|
||||
- https://github.com/Bisnode/opa-spring-security
|
||||
- https://github.com/build-security/opa-java-spring-client
|
||||
- https://github.com/massenz/jwt-opa
|
||||
- https://github.com/eugenp/tutorials/tree/master/spring-security-modules/spring-security-opa
|
||||
tutorials:
|
||||
- https://github.com/open-policy-agent/contrib/blob/master/spring_authz/README.md
|
||||
- https://github.com/massenz/jwt-opa#web-server-demo-app
|
||||
- https://www.baeldung.com/spring-security-authorization-opa
|
||||
inventors:
|
||||
- styra
|
||||
- build.security
|
||||
- bisnode
|
||||
- alertavert
|
||||
docs_features:
|
||||
rest-api-integration:
|
||||
note: |
|
||||
OPA Spring Security uses the REST API to query OPA about authz decisions.
|
||||
See an example application in OPA's
|
||||
[contrib repo](https://github.com/open-policy-agent/contrib/tree/main/spring_authz).
|
||||
layout: integration-single
|
||||
---
|
||||
Spring Security provides a framework for securing Java applications. These integrations provide simple implementations for Spring Security that use OPA for making API authorization decisions. They provide support for both traditional Spring Security (MVC), as well as an implementation for Spring Reactive (Web Flux).
|
||||
@@ -0,0 +1,16 @@
|
||||
---
|
||||
title: SQL Database Data Filtering
|
||||
labels:
|
||||
layer: data
|
||||
category: filtering
|
||||
software:
|
||||
- sqlite
|
||||
code:
|
||||
- https://github.com/open-policy-agent/contrib/tree/master/data_filter_example
|
||||
blogs:
|
||||
- https://blog.openpolicyagent.org/write-policy-in-opa-enforce-policy-in-sql-d9d24db93bf4
|
||||
inventors:
|
||||
- styra
|
||||
layout: integration-single
|
||||
---
|
||||
This integration enables the client of a SQL database to enhance a SQL query so that the results obey an OPA-defined policy.
|
||||
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: Strimzi (Apache Kafka on Kubernetes)
|
||||
software:
|
||||
- kafka
|
||||
- strimzi
|
||||
labels:
|
||||
category: streaming
|
||||
layer: data
|
||||
blogs:
|
||||
- https://strimzi.io/blog/2020/08/05/using-open-policy-agent-with-strimzi-and-apache-kafka/
|
||||
- https://strimzi.io/blog/2020/09/01/enforce-custom-resource-policies-with-opa-gatekeeper/
|
||||
code:
|
||||
- https://github.com/strimzi/strimzi-kafka-operator
|
||||
- https://github.com/scholzj/demo-opa-kafka-authorization
|
||||
- https://github.com/StyraInc/opa-kafka-plugin
|
||||
inventors:
|
||||
- redhat
|
||||
docs_features:
|
||||
rest-api-integration:
|
||||
note: |
|
||||
Strimzi can be configured to use OPA via the REST API as the Kafka
|
||||
authorizer using [this project](https://github.com/scholzj/demo-opa-kafka-authorization).
|
||||
layout: integration-single
|
||||
---
|
||||
Strimzi provides a way to run an Apache Kafka cluster on Kubernetes in various deployment configurations. Strimzi ships with the OPA authorizer plugin right out of the box, and supports OPA as an option for Kafka authorization.
|
||||
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: Styra Academy
|
||||
subtitle: OPA Learning Portal
|
||||
software: []
|
||||
inventors:
|
||||
- styra
|
||||
labels:
|
||||
category: learning
|
||||
type: poweredbyopa
|
||||
tutorials:
|
||||
- https://academy.styra.com
|
||||
- https://academy.styra.com/courses/opa-by-example
|
||||
- https://academy.styra.com/courses/opa-rego
|
||||
- https://academy.styra.com/courses/opa-k8s-admission-control
|
||||
- https://academy.styra.com/courses/opa-performance
|
||||
code:
|
||||
- https://github.com/StyraInc/academy-samples
|
||||
docs_features:
|
||||
learning-rego:
|
||||
note: |
|
||||
['OPA Policy Authoring'](https://academy.styra.com/courses/opa-rego)
|
||||
is a free course that teaches the fundamentals of writing Rego policies.
|
||||
layout: integration-single
|
||||
---
|
||||
Styra Academy is a free, self-paced learning portal for OPA and Styra Products.
|
||||
It includes a series of courses on a range of topics from beginner to advanced.
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user