Key Manager V1: Introduce ACL resources for secrets and containers

[kayrus]

Additional resources have to be introduced to cover the ACL functionality:

• openstack_keymanager_secret_access_v1
• openstack_keymanager_container_access_v1

Refs:

• https://github.com/terraform-providers/terraform-provider-openstack/pull/526#issuecomment-448825520
• https://docs.openstack.org/barbican/stein/api/reference/acls.html
• Keymanager V1: secrets resource #807
• Keymanager V1: container resource #808

@jtopjian @ozerovandrei do you approve additional resources or should they be embedded in the source resources?

UPD: the default ACL, applied on the secret/container is https://docs.openstack.org/api-guide/key-manager/acls.html#default-acl :

{
  "read": {
    "project-access": true
  }
}

[kayrus]

@jtopjian @ozerovandrei I analyzed the potential use cases. If we create an additional resource, which will set the ACLs, then there is a probability that there will be a gap between the secret creation and setting up the ACLs. During this gap the secret can be accessed by other users. This is different to manila shares ACLs, where the resource permissions are limited by default.

The barbican secret API allows to create the secret without the payload, then if there is no payload, it can be uploaded, but not updated. Using this behavior we can embed the ACL parameter into the secret resource and set ACLs during the resource creation:

• create the secret without the payload
• set the ACLs
• upload the payload

Thoughts?

[ozerovandrei]

@kayrus I guess that we could sacrifice the features that will come in case of decoupled resource (such as count, etc.) because of the security reasons that you explained.

So I think that we can embed ACLs safely.