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.
|
2019-10-25 17:29:02 +02:00
|
|
|
// Called with the "inputs" to the resource, before it is updated.
|
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-10-25 17:29:02 +02:00
|
|
|
// AnalyzeStack analyzes all resources within a stack, at the end of a successful
|
|
|
|
// preview or update. The provided resources are the "outputs", after any mutations
|
|
|
|
// have taken place.
|
|
|
|
rpc AnalyzeStack(AnalyzeStackRequest) 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 {
|
2020-02-08 01:11:34 +01:00
|
|
|
string type = 1; // the type token of the resource.
|
|
|
|
google.protobuf.Struct properties = 2; // the full properties to use for validation.
|
|
|
|
string urn = 3; // the URN of the resource.
|
|
|
|
string name = 4; // the name for the resource's URN.
|
|
|
|
AnalyzerResourceOptions options = 5; // the resource options.
|
|
|
|
AnalyzerProviderResource provider = 6; // the resource's provider.
|
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
|
|
|
}
|
|
|
|
|
2020-02-08 01:11:34 +01:00
|
|
|
// AnalyzerResource defines the view of a Pulumi-managed resource as sent to Analyzers. The properties
|
2019-10-25 17:29:02 +02:00
|
|
|
// of the resource are specific to the type of analysis being performed. See the Analyzer
|
|
|
|
// service definition for more information.
|
|
|
|
message AnalyzerResource {
|
2020-02-08 01:11:34 +01:00
|
|
|
string type = 1; // the type token of the resource.
|
|
|
|
google.protobuf.Struct properties = 2; // the full properties to use for validation.
|
|
|
|
string urn = 3; // the URN of the resource.
|
|
|
|
string name = 4; // the name for the resource's URN.
|
|
|
|
AnalyzerResourceOptions options = 5; // the resource options.
|
|
|
|
AnalyzerProviderResource provider = 6; // the resource's provider.
|
|
|
|
string parent = 7; // an optional parent URN that this child resource belongs to.
|
|
|
|
repeated string dependencies = 8; // a list of URNs that this resource depends on.
|
|
|
|
map<string, AnalyzerPropertyDependencies> propertyDependencies = 9; // a map from property keys to the dependencies of the property.
|
|
|
|
}
|
|
|
|
|
|
|
|
// AnalyzerResourceOptions defines the options associated with a resource.
|
|
|
|
message AnalyzerResourceOptions {
|
|
|
|
// CustomTimeouts allows a user to be able to create a set of custom timeout parameters.
|
|
|
|
message CustomTimeouts {
|
|
|
|
double create = 1; // The create resource timeout in seconds.
|
|
|
|
double update = 2; // The update resource timeout in seconds.
|
|
|
|
double delete = 3; // The delete resource timeout in seconds.
|
|
|
|
}
|
|
|
|
|
|
|
|
bool protect = 1; // true if the resource should be marked protected.
|
|
|
|
repeated string ignoreChanges = 2; // a list of property names to ignore during changes.
|
|
|
|
bool deleteBeforeReplace = 3; // true if this resource should be deleted before replacement.
|
|
|
|
bool deleteBeforeReplaceDefined = 4; // true if the deleteBeforeReplace property should be treated as defined even if it is false.
|
|
|
|
repeated string additionalSecretOutputs = 5; // a list of output properties that should also be treated as secret, in addition to ones we detect.
|
|
|
|
repeated string aliases = 6; // a list of additional URNs that shoud be considered the same.
|
|
|
|
CustomTimeouts customTimeouts = 7; // a config block that will be used to configure timeouts for CRUD operations.
|
|
|
|
}
|
|
|
|
|
|
|
|
// AnalyzerProviderResource provides information about a resource's provider.
|
|
|
|
message AnalyzerProviderResource {
|
2019-10-25 17:29:02 +02:00
|
|
|
string type = 1; // the type token of the resource.
|
|
|
|
google.protobuf.Struct properties = 2; // the full properties to use for validation.
|
2019-11-21 22:01:15 +01:00
|
|
|
string urn = 3; // the URN of the resource.
|
2020-02-08 01:11:34 +01:00
|
|
|
string name = 4; // the name for the resource's URN.
|
|
|
|
}
|
|
|
|
|
|
|
|
// AnalyzerPropertyDependencies describes the resources that a particular property depends on.
|
|
|
|
message AnalyzerPropertyDependencies {
|
|
|
|
repeated string urns = 1; // A list of URNs this property depends on.
|
2019-10-25 17:29:02 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
message AnalyzeStackRequest {
|
|
|
|
repeated AnalyzerResource resources = 1;
|
|
|
|
}
|
|
|
|
|
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.
|
2019-11-21 22:01:15 +01:00
|
|
|
string urn = 8; // URN of the resource that violates the policy.
|
2019-06-24 02:51:15 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
// 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
|
|
|
}
|