terraform-provider-oci
terraform-provider-oci copied to clipboard
oracle
OCI Object Storage backend
affected_resources=terraform
Community Note
- Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
- Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
- If you are interested in working on this issue or have submitted a pull request, please leave a comment
Description
Looking at the documenation of backends, we can see that every other major cloud provider has their own backend for Object Storage available.
All of them support locking TF state together with encryption in one form or the other.
New or Affected Resource(s)
OCI to introduce backend specifically tailored for Object Storage instead of retrofitting other backends.
I've been very happy with this config:
1 terraform {
2 backend "s3" {
3 bucket = "terraform-state"
4 key = "oci/terraform.tfstate"
5 region = "<REGION>"
6 endpoint = "https://<NAMESPACE>.compat.objectstorage.<REGION>.oraclecloud.com"
7 skip_region_validation = true
8 skip_credentials_validation = true
9 skip_metadata_api_check = true
10 force_path_style = true
11 }
12 }
What are you looking for, in addition to that?
Just realized today, that it also would be nice to have the single point of authentication mechanism, rather than using .oci/config for provider and AWS env vars for bucket.
Hi @kostasns , while I agree it would be nice to have one point of authentication for both backends and provider; the way that Terraform is currently designed doesn't allow for that. Terraform is designed in such a way that backends are completely opaque to the provider. In other words, Terraform providers do not have any control over backends and how they are configured. You will notice that this is why Terraform has separate syntax for defining backends and defining providers in their configs.
This seems like it would be good feedback for https://github.com/hashicorp/terraform to support unifying auth between providers and backends.
Hi @alexng-canuck, to come back to the topic. Looking at AWS provider and backend I can have a single set of access_key and secret_key ( or ENV variables ) set to interact with both: https://www.terraform.io/docs/backends/types/s3.html#access_key https://registry.terraform.io/providers/hashicorp/aws/latest/docs#environment-variables Or use shared credentials ..
This is basically what I was after when stating my initial comment around single point of authentication.
We are currently using Okta federated identity, and we do not have individual OCIDs or API keys for setting up the pseudo-S3 access. Consequently, direct OCI authentication would be faster for us to use as a Terraform backend.
We currently do not want to enable the Provisioned/Synchronized Users feature, to ensure that API keys without associated MFA will not supported in our organization.
This is a sorely needed feature to use terraform in a secure production environment. Some observations:
- Locking is a necessary feature in a collaborative environment. As OCI Object Storage supports read-after-write consistency, a lockfile could be used to implement this feature.
- Without a native object storage backend, using Instance Principal or Security Token authentication is not a complete solution as additional (non-ephemeral) credentials need to be used to authenticate to the S3 emulation backend.
We hope that any proper OCI remote backend will also support instance principal authentication.
while I agree it would be nice to have one point of authentication for both backends and provider; the way that Terraform is currently designed doesn't allow for that. ... Terraform has separate syntax for defining backends and defining providers in their configs.
This is a confusing comment to me. Yes, there is a separate config file for the backend, but we could point to $HOME/.oci/config from that file for authorization data if we wanted to. There's absolutely nothing to stop a new backend from parsing .oci/config if we chose to include that functionality. Then we still ultimately end up with "one point of authentication" which is pointed to by two different files.
We are very sorry that we couldn't respond to each and every issue reported on GitHub. Although we have refined the process to prioritize customer issues on GitHub, since this issue was reported a while ago, there is a good chance it may have been fixed in the latest version of Terraform Provider OCI. If you are still experiencing this issue, please create a new issue and label it as Bug.
@ravinitp I submitted feature request to Oracle under SR 3-32097896281 for Terraform state locking on Oracle backend, and Oracle opened a enhancement request R2-37831. Do you have access to those?
Also this problem was mentioned in https://github.com/oracle/terraform-provider-oci/issues/384#issuecomment-362364545
I'm had a meeting with Oracle today and requested that they know that our (my work) organisation is also requesting this feature.
@divansantana If you haven't done so already, I recommend that you open a ticket at https://support.oracle.com and refer to support ticket SR 3-32097896281 for Terraform state locking on Oracle backend, and enhancement request R2-37831.
That way in addition to the meeting you have, there will be an "official" audit that multiple customers are asking for the same thing.
How to declare access key and secret key in backend configuration.. I was trying to use with environment variables but it doesn't support that.. tried with echo the secrets in GitHub runner and refer those here with /.AWS/credentials file but it is throwing error for authorisation malformed issue can someone help me with correct and safe way to declare the access key and secret key
