2018-05-22 21:43:36 +02:00
|
|
|
// Copyright 2016-2018, Pulumi Corporation.
|
|
|
|
//
|
|
|
|
// Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
// you may not use this file except in compliance with the License.
|
|
|
|
// You may obtain a copy of the License at
|
|
|
|
//
|
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
//
|
|
|
|
// Unless required by applicable law or agreed to in writing, software
|
|
|
|
// distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
// See the License for the specific language governing permissions and
|
|
|
|
// limitations under the License.
|
Add basic analyzer support
This change introduces the basic requirements for analyzers, as per
pulumi/coconut#119. In particular, an analyzer can implement either,
or both, of the RPC methods, Analyze and AnalyzeResource. The former
is meant to check an overall deployment (e.g., to ensure it has been
signed off on) and the latter is to check individual resources (e.g.,
to ensure properties of them are correct, such as checking style,
security, etc. rules). These run simultaneous to overall checking.
Analyzers are loaded as plugins just like providers are. The difference
is mainly in their naming ("analyzer-" prefix, rather than "resource-"),
and the RPC methods that they support.
This isn't 100% functional since we need a way to specify at the CLI
that a particular analyzer should be run, in addition to a way of
recording which analyzers certain projects should use in their manifests.
2017-03-11 08:49:17 +01:00
|
|
|
|
|
|
|
syntax = "proto3";
|
|
|
|
|
2017-12-01 22:50:32 +01:00
|
|
|
import "plugin.proto";
|
|
|
|
import "google/protobuf/empty.proto";
|
Add basic analyzer support
This change introduces the basic requirements for analyzers, as per
pulumi/coconut#119. In particular, an analyzer can implement either,
or both, of the RPC methods, Analyze and AnalyzeResource. The former
is meant to check an overall deployment (e.g., to ensure it has been
signed off on) and the latter is to check individual resources (e.g.,
to ensure properties of them are correct, such as checking style,
security, etc. rules). These run simultaneous to overall checking.
Analyzers are loaded as plugins just like providers are. The difference
is mainly in their naming ("analyzer-" prefix, rather than "resource-"),
and the RPC methods that they support.
This isn't 100% functional since we need a way to specify at the CLI
that a particular analyzer should be run, in addition to a way of
recording which analyzers certain projects should use in their manifests.
2017-03-11 08:49:17 +01:00
|
|
|
import "google/protobuf/struct.proto";
|
|
|
|
|
2017-09-22 04:18:21 +02:00
|
|
|
package pulumirpc;
|
Add basic analyzer support
This change introduces the basic requirements for analyzers, as per
pulumi/coconut#119. In particular, an analyzer can implement either,
or both, of the RPC methods, Analyze and AnalyzeResource. The former
is meant to check an overall deployment (e.g., to ensure it has been
signed off on) and the latter is to check individual resources (e.g.,
to ensure properties of them are correct, such as checking style,
security, etc. rules). These run simultaneous to overall checking.
Analyzers are loaded as plugins just like providers are. The difference
is mainly in their naming ("analyzer-" prefix, rather than "resource-"),
and the RPC methods that they support.
This isn't 100% functional since we need a way to specify at the CLI
that a particular analyzer should be run, in addition to a way of
recording which analyzers certain projects should use in their manifests.
2017-03-11 08:49:17 +01:00
|
|
|
|
2019-06-24 02:51:15 +02:00
|
|
|
// Analyzer provides a pluggable interface for checking resource definitions against some number of
|
|
|
|
// resource policies. It is intentionally open-ended, allowing for implementations that check
|
|
|
|
// everything from raw resource definitions to entire projects/stacks/snapshots for arbitrary
|
|
|
|
// issues -- style, policy, correctness, security, and so on.
|
2017-03-11 19:07:34 +01:00
|
|
|
service Analyzer {
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
// Analyze analyzes a single resource object, and returns any errors that it finds.
|
Add basic analyzer support
This change introduces the basic requirements for analyzers, as per
pulumi/coconut#119. In particular, an analyzer can implement either,
or both, of the RPC methods, Analyze and AnalyzeResource. The former
is meant to check an overall deployment (e.g., to ensure it has been
signed off on) and the latter is to check individual resources (e.g.,
to ensure properties of them are correct, such as checking style,
security, etc. rules). These run simultaneous to overall checking.
Analyzers are loaded as plugins just like providers are. The difference
is mainly in their naming ("analyzer-" prefix, rather than "resource-"),
and the RPC methods that they support.
This isn't 100% functional since we need a way to specify at the CLI
that a particular analyzer should be run, in addition to a way of
recording which analyzers certain projects should use in their manifests.
2017-03-11 08:49:17 +01:00
|
|
|
rpc Analyze(AnalyzeRequest) returns (AnalyzeResponse) {}
|
2019-06-24 02:51:15 +02:00
|
|
|
// GetAnalyzerInfo returns metadata about the analyzer (e.g., list of policies contained).
|
|
|
|
rpc GetAnalyzerInfo(google.protobuf.Empty) returns (AnalyzerInfo) {}
|
2017-12-01 22:50:32 +01:00
|
|
|
// GetPluginInfo returns generic information about this plugin, like its version.
|
|
|
|
rpc GetPluginInfo(google.protobuf.Empty) returns (PluginInfo) {}
|
Add basic analyzer support
This change introduces the basic requirements for analyzers, as per
pulumi/coconut#119. In particular, an analyzer can implement either,
or both, of the RPC methods, Analyze and AnalyzeResource. The former
is meant to check an overall deployment (e.g., to ensure it has been
signed off on) and the latter is to check individual resources (e.g.,
to ensure properties of them are correct, such as checking style,
security, etc. rules). These run simultaneous to overall checking.
Analyzers are loaded as plugins just like providers are. The difference
is mainly in their naming ("analyzer-" prefix, rather than "resource-"),
and the RPC methods that they support.
This isn't 100% functional since we need a way to specify at the CLI
that a particular analyzer should be run, in addition to a way of
recording which analyzers certain projects should use in their manifests.
2017-03-11 08:49:17 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
message AnalyzeRequest {
|
|
|
|
string type = 1; // the type token of the resource.
|
|
|
|
google.protobuf.Struct properties = 2; // the full properties to use for validation.
|
|
|
|
}
|
|
|
|
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
message AnalyzeResponse {
|
2019-06-11 00:20:22 +02:00
|
|
|
repeated AnalyzeDiagnostic diagnostics = 2; // information about policy violations.
|
Add basic analyzer support
This change introduces the basic requirements for analyzers, as per
pulumi/coconut#119. In particular, an analyzer can implement either,
or both, of the RPC methods, Analyze and AnalyzeResource. The former
is meant to check an overall deployment (e.g., to ensure it has been
signed off on) and the latter is to check individual resources (e.g.,
to ensure properties of them are correct, such as checking style,
security, etc. rules). These run simultaneous to overall checking.
Analyzers are loaded as plugins just like providers are. The difference
is mainly in their naming ("analyzer-" prefix, rather than "resource-"),
and the RPC methods that they support.
This isn't 100% functional since we need a way to specify at the CLI
that a particular analyzer should be run, in addition to a way of
recording which analyzers certain projects should use in their manifests.
2017-03-11 08:49:17 +01:00
|
|
|
}
|
|
|
|
|
2019-06-24 02:51:15 +02:00
|
|
|
// EnforcementLevel indicates the severity of a policy violation.
|
|
|
|
enum EnforcementLevel {
|
|
|
|
ADVISORY = 0; // Displayed to users, but does not block deployment.
|
|
|
|
MANDATORY = 1; // Stops deployment, cannot be overridden.
|
|
|
|
}
|
|
|
|
|
2019-06-11 00:20:22 +02:00
|
|
|
message AnalyzeDiagnostic {
|
2019-06-24 02:51:15 +02:00
|
|
|
string policyName = 1; // Name of the violated policy.
|
|
|
|
string policyPackName = 2; // Name of the policy pack the policy is in.
|
|
|
|
string policyPackVersion = 3; // Version of the policy pack.
|
|
|
|
string description = 4; // Description of policy rule. e.g., "encryption enabled."
|
|
|
|
string message = 5; // Message to display on policy violation, e.g., remediation steps.
|
|
|
|
repeated string tags = 6; // Keywords/terms to associate with a policy, e.g., "cost".
|
|
|
|
EnforcementLevel enforcementLevel = 7; // Severity of the policy violation.
|
|
|
|
}
|
|
|
|
|
|
|
|
// AnalyzerInfo provides metadata about a PolicyPack inside an analyzer.
|
|
|
|
message AnalyzerInfo {
|
|
|
|
string name = 1; // Name of the PolicyPack.
|
|
|
|
string displayName = 2; // Pretty name for the PolicyPack.
|
|
|
|
repeated PolicyInfo policies = 3; // Metadata about policies contained in PolicyPack.
|
|
|
|
}
|
|
|
|
|
|
|
|
// PolicyInfo provides metadata about an individual Policy within a Policy Pack.
|
|
|
|
message PolicyInfo {
|
|
|
|
string name = 1; // Name of the policy.
|
|
|
|
string displayName = 2; // Pretty name for the policy.
|
|
|
|
string description = 3; // Description of policy rule. e.g., "encryption enabled."
|
|
|
|
string message = 4; // Message to display on policy violation, e.g., remediation steps.
|
|
|
|
EnforcementLevel enforcementLevel = 5; // Severity of the policy violation.
|
Add basic analyzer support
This change introduces the basic requirements for analyzers, as per
pulumi/coconut#119. In particular, an analyzer can implement either,
or both, of the RPC methods, Analyze and AnalyzeResource. The former
is meant to check an overall deployment (e.g., to ensure it has been
signed off on) and the latter is to check individual resources (e.g.,
to ensure properties of them are correct, such as checking style,
security, etc. rules). These run simultaneous to overall checking.
Analyzers are loaded as plugins just like providers are. The difference
is mainly in their naming ("analyzer-" prefix, rather than "resource-"),
and the RPC methods that they support.
This isn't 100% functional since we need a way to specify at the CLI
that a particular analyzer should be run, in addition to a way of
recording which analyzers certain projects should use in their manifests.
2017-03-11 08:49:17 +01:00
|
|
|
}
|