Request for aws_opensearchserverless_* resource

[stevendborrelli]

What resource do you need?

Support Opensearch Serverless (https://aws.amazon.com/opensearch-service/features/serverless/)

Terraform Resource Names:

• aws_opensearchserverless_access_policy
• aws_opensearchserverless_collection
• aws_opensearchserverless_lifecycle_policy
• aws_opensearchserverless_security_config
• aws_opensearchserverless_security_policy
• aws_opensearchserverless_vpc_endpoint

[stevendborrelli]

@turkenf are you currently working on this? I have some bandwidth to work on it.

[turkenf]

@stevendborrelli I haven't started working on it yet, actually, I've been waiting to hear from you so I can prioritize it.

[blakeromano]

This is a big need for us so we'd heavily appreciate this 😃

[jeanduplessis]

Please note these resources are not available in v4 of the Terraform AWS provider. The earliest version it becomes available in is v5.3.0. This requires a major version bump in the Terraform provider which brings with it a multitude of breaking API changes.

Upgrading to v5 of the Terraform AWS provider is on our roadmap for this quarter.

[ulucinar]

Hi @turkenf,
I have no previous experience with SAML but my current understanding is that the SAML idP metadata (relevant for the aws_opensearchserverless_security_config resource) does not inherently contain any sensitive data and is meant to be shared between identity providers in public. So, it looks like it's okay to make samlOptions.metadata as part of the spec. Also terraform did not choose to make it sensitive, which supports this.

But still, I think it's a better idea to make spec.forProvider.samlOptions.metadata a secret reference, i.e., the controller reads the SAML metadata from a Kubernetes secret instead of directly reading it from the spec:

• The accepted XML documents for this parameter can be as large as 20KB. It's generally not a good UX to supply such large documents via the spec of a custom resource.
• There might be organizational policies/practices in favor of Kubernetes secrets/configmaps for such configuration data. One aspect of this metadata is that it contains a signing/encryption certificate, which are associated with private keys, which are in turn sensitive data. So, it might make sense, for some people, to manage/evolve the SAML IdP metadata in Kubernetes secrets, closer to the associated sensitive metadata.

So, my suggestion is to make spec.forProvider.samlOptions.metadata a K8s secret reference, and leaving this as a comment here for feedback.

Btw, we may use the following metadata document in our validation tests for the resource:

<?xml version="1.0"?>
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" validUntil="2034-02-11T09:05:03Z" cacheDuration="PT1708074303S" entityID="example-entity">
  <md:IDPSSODescriptor WantAuthnRequestsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <md:KeyDescriptor use="signing">
      <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:X509Data>
          <ds:X509Certificate>MIIDezCCAmOgAwIBAgIUWxbJ2eoILVDDj7tucPTVl6fxqhIwDQYJKoZIhvcNAQELBQAwNzELMAkGA1UEBhMCVFIxKDAmBgNVBAMMH3Byb3ZpZGVyLWF3cy51cGJvdW5kLXN5c3RlbS5zdmMwHhcNMjQwMjA5MDkwNDQyWhcNMjUwMjA4MDkwNDQyWjA3MQswCQYDVQQGEwJUUjEoMCYGA1UEAwwfcHJvdmlkZXItYXdzLnVwYm91bmQtc3lzdGVtLnN2YzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANxLbvqITbFJM2vf1XqSJTffymx9oejUe2AAhP7BCLw4Lc46X8c9xvHiU+HQlaIZaRdzffUdiv2OBeDe4ojVrcQDlzaUCdRJTTi8l2PScla4JGFBCIg727fdbhf4tMchXzpPtxJY2JhJPkkB0G1Q/ly/AjXIeTkqnngOL6x+9zYFFDfBhPMSNZoBtuKPPM4rTWQL+k4+r7cDVAY5Mr9DhjhEJM4ZP0GbOmSEaQmDSGe3mFxiMaAnE1laf1Pb1MbfPCJ5fhbs20oTQeznnWr8Jxam5245LN/joilzVs/lePWM8I1+tY4+W1gkfGqhSEJpUDhYPobtcoHoqu/cl1o1YXkCAwEAAaN/MH0wHQYDVR0OBBYEFG3W1JJviPwnGNl1Uwu8NsLsHSp6MB8GA1UdIwQYMBaAFG3W1JJviPwnGNl1Uwu8NsLsHSp6MA8GA1UdEwEB/wQFMAMBAf8wKgYDVR0RBCMwIYIfcHJvdmlkZXItYXdzLnVwYm91bmQtc3lzdGVtLnN2YzANBgkqhkiG9w0BAQsFAAOCAQEAGph/2wqfF3FVh0Esf3Mr1zWRbVL14QmWkd9uzXjePKnQNgH8EdftD1XUk66XthpPMfbuWZJ8wpZwETEkoSPHkm88uHQVpjUq2X/fP7KGx3x7Q3a6sZriBjrM4nEoaL6PaKrJIBOv07ul5V88XE0GYQsXzDw1h38yWJ54sMbx6THTPELn7LMPPIwSMJ2t2KmJTPYbtnmG+Ii7VqVQLha+z0eLpaM7vBsNXGrrZTzVRPIt6JnardzDWdbZoJ0gBVof3XL0cI1jef2XhakN1+JtYPTaXkV4Lwa5i7zS9pIKnzwGPXHFOEftvFcc+Yqluj1+RdYJUsIiiKSHIp6bA80qfA==</ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </md:KeyDescriptor>
    <md:KeyDescriptor use="encryption">
      <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:X509Data>
          <ds:X509Certificate>MIIDezCCAmOgAwIBAgIUWxbJ2eoILVDDj7tucPTVl6fxqhIwDQYJKoZIhvcNAQELBQAwNzELMAkGA1UEBhMCVFIxKDAmBgNVBAMMH3Byb3ZpZGVyLWF3cy51cGJvdW5kLXN5c3RlbS5zdmMwHhcNMjQwMjA5MDkwNDQyWhcNMjUwMjA4MDkwNDQyWjA3MQswCQYDVQQGEwJUUjEoMCYGA1UEAwwfcHJvdmlkZXItYXdzLnVwYm91bmQtc3lzdGVtLnN2YzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANxLbvqITbFJM2vf1XqSJTffymx9oejUe2AAhP7BCLw4Lc46X8c9xvHiU+HQlaIZaRdzffUdiv2OBeDe4ojVrcQDlzaUCdRJTTi8l2PScla4JGFBCIg727fdbhf4tMchXzpPtxJY2JhJPkkB0G1Q/ly/AjXIeTkqnngOL6x+9zYFFDfBhPMSNZoBtuKPPM4rTWQL+k4+r7cDVAY5Mr9DhjhEJM4ZP0GbOmSEaQmDSGe3mFxiMaAnE1laf1Pb1MbfPCJ5fhbs20oTQeznnWr8Jxam5245LN/joilzVs/lePWM8I1+tY4+W1gkfGqhSEJpUDhYPobtcoHoqu/cl1o1YXkCAwEAAaN/MH0wHQYDVR0OBBYEFG3W1JJviPwnGNl1Uwu8NsLsHSp6MB8GA1UdIwQYMBaAFG3W1JJviPwnGNl1Uwu8NsLsHSp6MA8GA1UdEwEB/wQFMAMBAf8wKgYDVR0RBCMwIYIfcHJvdmlkZXItYXdzLnVwYm91bmQtc3lzdGVtLnN2YzANBgkqhkiG9w0BAQsFAAOCAQEAGph/2wqfF3FVh0Esf3Mr1zWRbVL14QmWkd9uzXjePKnQNgH8EdftD1XUk66XthpPMfbuWZJ8wpZwETEkoSPHkm88uHQVpjUq2X/fP7KGx3x7Q3a6sZriBjrM4nEoaL6PaKrJIBOv07ul5V88XE0GYQsXzDw1h38yWJ54sMbx6THTPELn7LMPPIwSMJ2t2KmJTPYbtnmG+Ii7VqVQLha+z0eLpaM7vBsNXGrrZTzVRPIt6JnardzDWdbZoJ0gBVof3XL0cI1jef2XhakN1+JtYPTaXkV4Lwa5i7zS9pIKnzwGPXHFOEftvFcc+Yqluj1+RdYJUsIiiKSHIp6bA80qfA==</ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </md:KeyDescriptor>
    <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat>
    <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://example.com"/>
  </md:IDPSSODescriptor>
</md:EntityDescriptor>

Not sure if AWS does a certificate validation and will reject an expired certificate for future validation runs, but I don't think so.