containersolutions / argus Goto Github PK

Metrics should contain TotalAttestations and PassedAttestations. Should contain labels

argus.io/resource
argus.io/requirement
argus.io/implementation

List potential solutions that could solve the WebApp use case.

• Are they open source, open core or closed source?
• What part of the use case do they allow to solve?

Resource Attestation should emit controller metrics on whether that specific attestation is a success or a failure.

The metric should be labeled leveraging the following set of labels available on the ResourceAttestation Manifest:

argus.io/resource
argus.io/requirement
argus.io/implementation
argus.io/attestation

We need to have some common definition of all of the 7(8 or 9?) CRDs before starting to actually touch the controllers

scheduling service might not be done independently, and instead be part of the runtime engine (see ADR #x)

This issue serves as control group so that we have a better idea about what exists and how things can be done without Argus.

This use case is composed of the following statements:

Requirement:

• Webapp must have a Load Balancer setup for resiliency

Implementation:

• Load Balancer implementation

Attestation:

• Stop one of the VMs, check the Webapp is still available; Restart the VMs

Resources:

• One Compliant Webapp (Webapp 1)
• One Non compliant Webapp (Webapp 2)

The existing solution(s) shall evaluate the Attestation for both Resources and verify that Webapp1 is compliant, while Webapp2 is not compliant.

• Implementations Controller

  • Responsible to invalidate a given Attestation set if a Requirement ResourceVersion changes
  • Creates child "ResourceImplementation" manifests and manages their lifecycle

• ResourceImplementation Controller

  • Responsible for keeping track if a given set of ResourceAttestation results validate a given Implementation for a given resource

These controllers can be implemented as long as resource CRD already exists. They should be fairly simple as they only need to query other CRDs and summarize information.

Has a dependency on ResourceAttestation.

List potential solutions that could solve the AWS Account use case.

• Are they open source, open core or closed source?
• What part of the use case do they allow to solve?

Argus must be able to run a custom command to verify if a given attestation is valid.

Argus must support commands to succeed (e.g. running conftest on a terraform definition should pass) or to fail (e.g. deploying a non-compliant resource that should be blocked) as ways to attestate a given Implementation

Command line attestation might be useful for debugging purposes, but may not be essential. If the implementations focus on e.g. a web server, a job despatching / running the attestations should be enough.

ResourceRequirement metrics should be based on NeededImplementations TotalImplementations and ValidImplementations. It should emit the metric with the following labels:

argus.io/resource
argus.io/requirement

formation logic:

NeededImplementations = number of implementations that are described on the Requirement spec
TotalImplementations = number of ResourceImplementations bound to this Requirement (i.e. how many things were said to be implemented)
ValidImplementations = number of Implementations which had their Attestation check passing.

This use case is composed of the following statements:

Requirement:

• S3 Buckets cannot be public

Implementation:

• AWS SCP

Attestation:

• Trying to create public buckets on AWS account, see it fail

Resources:

• One Compliant AWS account (AWS 1)
• One Non compliant AWS account (AWS 2)

Argus shall evaluate the Attestation for both Resources and verify that AWS 1 is compliant, while AWS 2 is not compliant.

Implementations must be linked to a resource and a specific requirement. The implementation must be the object that represents that a given requirement has been considered and thought of for a given resource.

Requirements that are not applicable for a given resource (e.g. there is no way to configure it) must still have a noOp implementation, or equivalent.

Implementations Must allow for Attestations to be bound there, so Argus can confirm that the given implementation is backed by an artifact.

The runtime registry service might not be done, as depending if the event bus is going to be behind the gateway api or not (see ADR #x). If it is behind the gateway API, there is no point of having a registry service for runtime instances.

As part of Argus, users should be able to register requirements that can then be used to target whatever resource Argus is overseeing.

Users must be able to specify requirements. Argus must properly handle requirement versioning, e.g. by using a git source.

Requirements should be compatible with industry standard requirements.

This use case is composed of the following statements:

Requirement:

• Webapp must have a Load Balancer setup for resiliency

Implementation:

• Load Balancer implementation

Attestation:

• Stop one of the VMs, check the Webapp is still available; Restart the VMs

Resources:

• One Compliant Webapp (Webapp 1)
• One Non compliant Webapp (Webapp 2)

Argus shall evaluate the Attestation for both Resources and verify that Webapp1 is compliant, while Webapp2 is not compliant.

Test existing solutions.

• Are they convenient to implement?
• Do they work as expected?
• Is there anything missing?

Solutions to test/tested:

• To edit when solution is found.

template:

Name - what will focus.

Write short report on the conclusions about each solution.

Report to write/written:

• To be edited with tested solution.

This use case is composed of the following statements:

Requirement:

• Privileged Containers should not be allowed in Kubernetes Clusters

Implementation:

• OPA Gatekeeper Policy

Attestation:

• Test of the policy definition

Resources:

• One Compliant Kubernetes Cluster (Cluster 1)
• One Non compliant Kubernetes cluster (Cluster 2)

Argus shall evaluate the Attestation for both Resources and verify that Cluster 1 is compliant, while Cluster 2 is not compliant.

Network Attestation provider should work by making http/REST calls to a configurable endpoint.

Resources are objects that Argus monitors. Each resource should have properties to indicate what are the categories they refer to, in order to link them back to which requirements actually apply to those resources.

Resource must be linkable to parent resources, as a way to inherit implementations from the parent resource as well.

Repository will store ADRs, issues, and general project documentation.

This issue serves as control group so that we have a better idea about what exists and how things can be done without Argus.

This use case is composed of the following statements:

Requirement:

• Privileged Containers should not be allowed in Kubernetes Clusters

Implementation:

• OPA Gatekeeper Policy

Attestation:

• Test of the policy definition

Resources:

• One Compliant Kubernetes Cluster (Cluster 1)
• One Non compliant Kubernetes cluster (Cluster 2)

The existing solution(s) shall evaluate the Attestation for both Resources and verify that Cluster 1 is compliant, while Cluster 2 is not compliant.

• Requirements Controller

  • Responsible for keeping track of Requirement Version.
  • Creates child "ResourceRequirement" manifests (like a replicaset creates a pod) and manages their lifecycle

• ResourceRequirements Controller

  • Keeps track of Resource compliance to individual Requirement based on The ResourceImplementation
    available for that Resource

these ones are fairly easy to implement as long as Resource CRD are defined. Has a dependency on ResourceImplementation

List potential solutions that could solve the Kubernetes use case.

• Are they open source, open core or closed source?
• What part of the use case do they allow to solve?

Write short report on the conclusions about each solution.

Report to write/written:

• To be edited with tested solution.

• Attestations Controller

  • Responsible to map out Resources needed to Attest.
  • Creates child "ResourceAttestation" manifests (aka pod to replicaset) and manages their lifecycle

• ResourceAttestations Controller

  • Based on a Resource, and on a provider, executes the provider call and gets the output
  • Tracks the output of the Attestation with logs, execution date, etc.

These two controllers can be implemented easily as long as Resource and Implementation CRDs are defined.

A tricky bit for this specific Controller is that it should allow from start the usage of AttestationProvider, which needs to be defined by (most likely) another CRD (AttestationProviderClass)?

For starters we can have a AttestationProviderClass which is just a webhook call, with the webhook parameters defined on the class.

Resource Metrics should be generated based on TotalRequirements and ImplementedRequirements field.

It should be labeled with the following label:

argus.io/resource

Test existing solutions.

• Are they convenient to implement?
• Do they work as expected?
• Is there anything missing?

Solutions to test/tested:

• To edit when solution is found.

grafana and prometheus operator should be installed by a make deploy.metrics command

Test existing solutions.

• Are they convenient to implement?
• Do they work as expected?
• Is there anything missing?

Solutions to test/tested:

• To edit when solution is found.

This issue serves as control group so that we have a better idea about what exists and how things can be done without Argus.

This use case is composed of the following statements:

Requirement:

• S3 Buckets cannot be public

Implementation:

• AWS SCP

Attestation:

• Trying to create public buckets on AWS account, see it fail

Resources:

• One Compliant AWS account (AWS 1)
• One Non compliant AWS account (AWS 2)

The existing solution(s) shall evaluate the Attestation for both Resources and verify that AWS 1 is compliant, while AWS 2 is not compliant.

Resource Controller should :

• Resources Controller
  • Responsible from keeping track of resource implementation, including nesting resolution (Implementation on Parent cascading to Child)
  • Responsible from keeping track of resource compliance, including nesting resolution (Compliance on Child cascading to Parent)
  • Responsible from Keeping track of Valid implementations from ResourceImplementation Manifests
  • Issue metrics :)

Probably one of the last controllers that we will implement

Write short report on the conclusions about each solution.

Report to write/written:

• To be edited with tested solution.

Argus must be able to verify implementations through verification of Test artifacts available on Github.

Argus should be able to read the test artifact manifest and query for a specific test case to verify if that specific test case has passed or not.