support sealwrap

benchmarktests/target_auth_aws.go

@@ -41,11 +41,13 @@ type AWSAuth struct {
 	header     http.Header
 	config     *AWSAuthTestConfig
 	logger     hclog.Logger
+	sealWrap   bool
 }
 
 type AWSAuthTestConfig struct {
 	AWSAuthConfig     *AWSAuthConfig     `hcl:"auth,block"`
 	AWSTestUserConfig *AWSTestUserConfig `hcl:"test_user,block"`
+	SealWrap          bool               `hcl:"seal_wrap,optional"`
 }
 
 type AWSAuthConfig struct {
@@ -100,6 +102,7 @@ func (a *AWSAuth) ParseConfig(body hcl.Body) error {
 				SecretKey: os.Getenv(AWSAuthSecretKey),
 			},
 			AWSTestUserConfig: &AWSTestUserConfig{},
+			SealWrap:          a.config.SealWrap,
 		},
 	}
 
@@ -162,7 +165,8 @@ func (a *AWSAuth) Setup(client *api.Client, mountName string, topLevelConfig *To
 	// Create AWS Auth mount
 	a.logger.Trace(mountLogMessage("auth", "aws", authPath))
 	err = client.Sys().EnableAuthWithOptions(authPath, &api.EnableAuthOptions{
-		Type: "aws",
+		Type:     "aws",
+		SealWrap: a.config.SealWrap,
 	})
 	if err != nil {
 		return nil, fmt.Errorf("error enabling aws: %v", err)

benchmarktests/target_secret_aws.go

@@ -38,12 +38,14 @@ type AWSTest struct {
 	roleName   string
 	config     *AWSSecretTestConfig
 	logger     hclog.Logger
+	sealWrap   bool
 }
 
 // Main Config Struct
 type AWSSecretTestConfig struct {
 	AWSConnectionConfig *AWSConnectionConfig `hcl:"connection,block"`
 	AWSRoleConfig       *AWSRoleConfig       `hcl:"role,block"`
+	SealWrap            bool                 `hcl:"seal_wrap,optional"`
 }
 
 type AWSConnectionConfig struct {
@@ -83,6 +85,7 @@ func (a *AWSTest) ParseConfig(body hcl.Body) error {
 				Name:           "benchmark-role",
 				CredentialType: "iam_user",
 			},
+			SealWrap: false,
 		},
 	}
 
@@ -141,7 +144,8 @@ func (a *AWSTest) Setup(client *api.Client, mountName string, topLevelConfig *To
 
 	a.logger.Trace(mountLogMessage("secrets", "aws", secretPath))
 	err = client.Sys().Mount(secretPath, &api.MountInput{
-		Type: "aws",
+		Type:     "aws",
+		SealWrap: a.sealWrap,
 	})
 	if err != nil {
 		return nil, fmt.Errorf("error mounting aws secrets engine: %v", err)

benchmarktests/target_secret_kvv2.go

@@ -45,20 +45,23 @@ type KVV2Test struct {
 	numKVs     int
 	kvSize     int
 	logger     hclog.Logger
+	sealWrap   bool
 }
 
 type KVV2SecretTestConfig struct {
-	KVSize int `hcl:"kvsize,optional"`
-	NumKVs int `hcl:"numkvs,optional"`
+	KVSize   int  `hcl:"kvsize,optional"`
+	NumKVs   int  `hcl:"numkvs,optional"`
+	SealWrap bool `hcl:"sealWrap,optional"`
 }
 
 func (k *KVV2Test) ParseConfig(body hcl.Body) error {
 	testConfig := &struct {
 		Config *KVV2SecretTestConfig `hcl:"config,block"`
 	}{
 		Config: &KVV2SecretTestConfig{
-			KVSize: 1,
-			NumKVs: 1000,
+			KVSize:   1,
+			NumKVs:   1000,
+			SealWrap: false,
 		},
 	}
 
@@ -145,6 +148,7 @@ func (k *KVV2Test) Setup(client *api.Client, mountName string, topLevelConfig *T
 		Options: map[string]string{
 			"version": "2",
 		},
+		SealWrap: k.config.SealWrap,
 	})
 	if err != nil {
 		return nil, fmt.Errorf("error mounting kv secrets engine: %v", err)
@@ -178,6 +182,7 @@ func (k *KVV2Test) Setup(client *api.Client, mountName string, topLevelConfig *T
 		kvSize:     k.config.KVSize,
 		logger:     k.logger,
 		action:     k.action,
+		sealWrap:   k.config.SealWrap,
 	}, nil
 }
 

docs/tests/auth-aws.md

@@ -32,15 +32,16 @@ This benchmark tests the performance of logins using the AWS auth method.
 - `bound_iam_principal_arn` `(list: [])` - Defines the list of IAM principals that are permitted to login to the role using the iam auth method. Individual values should look like "arn:aws:iam::123456789012:user/MyUserName" or "arn:aws:iam::123456789012:role/MyRoleName". Wildcards are supported at the end of the ARN, e.g., "arn:aws:iam::123456789012:\*" will match any IAM principal in the AWS account 123456789012. When `resolve_aws_unique_ids` is `false` and you are binding to IAM roles (as opposed to users) and you are not using a wildcard at the end, then you must specify the ARN by omitting any path component; see the documentation for `resolve_aws_unique_ids` below. This constraint is only checked by the iam auth method. Wildcards are supported at the end of the ARN, e.g., "arn:aws:iam::123456789012:role/\*" will match all roles in the AWS account. This is a comma-separated string or JSON array.
 - `inferred_entity_type` `(string: "")` - When set, instructs Vault to turn on inferencing. The only current valid value is "ec2_instance" instructing Vault to infer that the role comes from an EC2 instance in an IAM instance profile. This only applies to the iam auth method. If you set this on an existing role where it had not previously been set, tokens that had been created prior will not be renewable; clients will need to get a new token.
 - `inferred_aws_region` `(string: "")` - When role inferencing is activated, the region to search for the inferred entities (e.g., EC2 instances). Required if role inferencing is activated. This only applies to the iam auth method.
-- `resolve_aws_unique_ids` `(bool: true)` - When set, resolves the `bound_iam_principal_arn` to the [AWS Unique ID](http://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers#identifiers-unique-ids) for the bound principal ARN. This field is ignored when `bound_iam_principal_arn` ends with a wildcard character. This requires Vault to be able to call `iam:GetUser` or `iam:GetRole` on the `bound_iam_principal_arn` that is being bound. Resolving to internal AWS IDs more closely mimics the behavior of AWS services in that if an IAM user or role is deleted and a new one is recreated with the same name, those new users or roles won't get access to roles in Vault that were permissioned to the prior principals of the same name. The default value for new roles is true, while the default value for roles that existed prior to this option existing is false (you can check the value for a given role using the GET method on the role). Any authentication tokens created prior to this being supported won't verify the unique ID upon token renewal. When this is changed from false to true on an existing role, Vault will attempt to resolve the role's bound IAM ARN to the unique ID and, if unable to do so, will fail to enable this option. Changing this from `true` to `false` is not supported; if absolutely necessary, you would need to delete the role and recreate it explicitly setting it to `false`. However; the instances in which you would want to do this should be rare. If the role creation (or upgrading to use this) succeed, then Vault has already been able to resolve internal IDs, and it doesn't need any further IAM permissions to authenticate users. If a role has been deleted and recreated, and Vault has cached the old unique ID, you should just call this endpoint specifying the same `bound_iam_principal_arn` and, as long as Vault still has the necessary IAM permissions to resolve the unique ID, Vault will update the unique ID. (If it does not have the necessary permissions to resolve the unique ID, then it will fail to update.) If this option is set to false, then you MUST leave out the path component in `bound_iam_principal_arn` for **roles** that do not specify a wildcard at the end, but not IAM users or role bindings that have a wildcard. That is, if your IAM role ARN is of the form `arn:aws:iam::123456789012:role/some/path/to/MyRoleName`, and `resolve_aws_unique_ids` is `false`, you **must** specify a `bound_iam_principal_arn` of `arn:aws:iam::123456789012:role/MyRoleName` for authentication to work. - `allow_instance_migration` `(bool: false)` - If set, allows migration of the underlying instance where the client resides. This keys off of pendingTime in the metadata document, so essentially, this disables the client nonce check whenever the instance is migrated to a new host and pendingTime is newer than the previously-remembered time. Use with caution. This only applies to authentications via the ec2 auth method. This is mutually exclusive with `disallow_reauthentication`.
+- `resolve_aws_unique_ids` `(bool: true)` - When set, resolves the `bound_iam_principal_arn` to the [AWS Unique ID](http://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers#identifiers-unique-ids) for the bound principal ARN. This field is ignored when `bound_iam_principal_arn` ends with a wildcard character. This requires Vault to be able to call `iam:GetUser` or `iam:GetRole` on the `bound_iam_principal_arn` that is being bound. Resolving to internal AWS IDs more closely mimics the behavior of AWS services in that if an IAM user or role is deleted and a new one is recreated with the same name, those new users or roles won't get access to roles in Vault that were permissioned to the prior principals of the same name. The default value for new roles is true, while the default value for roles that existed prior to this option existing is false (you can check the value for a given role using the GET method on the role). Any authentication tokens created prior to this being supported won't verify the unique ID upon token renewal. When this is changed from false to true on an existing role, Vault will attempt to resolve the role's bound IAM ARN to the unique ID and, if unable to do so, will fail to enable this option. Changing this from `true` to `false` is not supported; if absolutely necessary, you would need to delete the role and recreate it explicitly setting it to `false`. However; the instances in which you would want to do this should be rare. If the role creation (or upgrading to use this) succeed, then Vault has already been able to resolve internal IDs, and it doesn't need any further IAM permissions to authenticate users. If a role has been deleted and recreated, and Vault has cached the old unique ID, you should just call this endpoint specifying the same `bound_iam_principal_arn` and, as long as Vault still has the necessary IAM permissions to resolve the unique ID, Vault will update the unique ID. (If it does not have the necessary permissions to resolve the unique ID, then it will fail to update.) If this option is set to false, then you MUST leave out the path component in `bound_iam_principal_arn` for __roles__ that do not specify a wildcard at the end, but not IAM users or role bindings that have a wildcard. That is, if your IAM role ARN is of the form `arn:aws:iam::123456789012:role/some/path/to/MyRoleName`, and `resolve_aws_unique_ids` is `false`, you __must__ specify a `bound_iam_principal_arn` of `arn:aws:iam::123456789012:role/MyRoleName` for authentication to work. - `allow_instance_migration` `(bool: false)` - If set, allows migration of the underlying instance where the client resides. This keys off of pendingTime in the metadata document, so essentially, this disables the client nonce check whenever the instance is migrated to a new host and pendingTime is newer than the previously-remembered time. Use with caution. This only applies to authentications via the ec2 auth method. This is mutually exclusive with `disallow_reauthentication`.
 - `disallow_reauthentication` `(bool: false)` - If set, only allows a single token to be granted per instance ID. In order to perform a fresh login, the entry in the access list for the instance ID needs to be cleared using `auth/aws/identity-accesslist/<instance_id>` endpoint. Defaults to 'false'. This only applies to authentications via the ec2 auth method. This is mutually exclusive with `allow_instance_migration`.
 
 ## Example HCL
 
-```hcl
+```hcl {"id":"01J7XTS6FA7M3F0J3R6GY523AC"}
 test "aws_auth" "aws_test_1" {
     weight = 100
     config {
+        sealwrap = false
         auth {
             access_key = "$AWS_ACCESS_KEY"
             secret_key = "$AWS_SECRET_ACCESS_KEY"

docs/tests/secret-kv.md

@@ -7,17 +7,19 @@ This benchmark tests the performance of KVV1 and/or KVV2.  It writes a set numbe
 ### Configuration `config`
 
 - `numkvs` `(int: 1000)` - if any kvv1 or kvv2 requests are specified,
-then this many keys will be written during the setup phase.  The read operations
-will read from these keys, and the write operations overwrite them.
+   then this many keys will be written during the setup phase.  The read operations
+   will read from these keys, and the write operations overwrite them.
 - `kvsize` `(int: 1)`:  the size of the key and value to write.
+- `sealwrap` `(bool: false)` - if true, then the mount will be seal wrapped.
 
 ## Example Configuration
 
-```hcl
+```hcl {"id":"01J7XTST0KZYXCMVQSDDMZCB10"}
 test "kvv2_read" "kvv2_read_test" {
     weight = 50
     config {
         numkvs = 100
+        sealwrap = false
     }
 }
 
@@ -26,6 +28,7 @@ test "kvv2_write" "kvv2_write_test" {
     config {
         numkvs = 10
         kvsize = 1000
+        sealwrap = false
     }
 }
 ```