DEV Community: Thiago Arrais

Storing your Terraform state in Ceph (2023)

Thiago Arrais — Fri, 10 Nov 2023 20:47:41 +0000

This works with Terraform 1.6 and beyond. If you're using 1.5.x or earlier, try my older post on this matter

If you've got access to a Ceph instance, you can use the S3 backend to store the Terraform state. The usage is pretty much the same as for S3 itself, we just need to make sure to set the following arguments:

endpoints.s3
skip_credentials_validation
skip_region_validation
skip_requesting_account_id
skip_s3_checksum
use_path_style

endpoints.s3 should be set to the root URL served by your Ceph instance.

skip_credentials_validation controls whether the backend validates credentials against Amazon STS. Since you can't count on STS to validate your Ceph credentials, this should be set to true.

skip_region_validation should be set because Ceph doesn't actually use the provided region name and can't validate it.

skip_requesting_account_id should be set because Ceph doesn't provide the needed IAM API. It instead authenticates you using access and secret keys.

skip_s3_checksum should be set because Ceph does not include the checksum in its validation. If Terraform tries to write state to Ceph while this isn't in place, you'll get a XAmzContentSHA256Mismatch error.

use_path_style controls if bucket names are specified in subdomains (e.g. mybucket.myceph.myintranet) or in paths (e.g. myceph.myintranet/mybucket). The path style is more compatible with Ceph, so this also should be set to true.

Here is a copy-and-paste friendly version:

terraform {
  required_version = ">= 1.6.0"

  backend "s3" {
    bucket      = "your-bucket-name"
    key         = "a-key"
    region      = "us-east-1"
    access_key  = "your-access-key"
    secret_key  = "your-secret-key"

    skip_credentials_validation = true
    skip_region_validation      = true
    skip_requesting_account_id  = true
    skip_s3_checksum            = true
    use_path_style              = true

    endpoints = {
      s3      = "https://hostname.for.the.ceph.instance"
    }
  }
}

How to check if a server will accept your client certificate

Thiago Arrais — Sun, 15 Aug 2021 20:54:02 +0000

A currently fading but still very common way to authenticate client applications to serving applications is to use TLS/SSL client certificates. That way you can take advantage of the existing HTTPS infrastructure and just check the client serial number against a known list of authorized applications.

This is very commonly done in an enterprise setting where the certificate issuing process can be delegated to a third party. But this also means that the internal Certificate Authority may not be readily trusted by the server application infrastructure.

When that happens, the client may not be 100% sure that the server will trust its certificate. When it comes time to renew client certificates — and maybe even authorities — anxiety invariably kicks in!

Here's what you'll need

OpenSSL got you covered, of course. But OpenSSL is no easy beast to deal with.

The command you're looking for is openssl verify. It takes as input a certificate authority list, which comes from the server application team, and a client certificate, which comes from the client application team.

With both of those files in hand, here is what you'll need to say in your trusty shell:



$ openssl verify \
    -no-CApath \
    -CAfile certificate_authority_list.pem \
    client_certificate.pem

Do not forget to include the -noCApath flag or else OpenSSL will use your computer's trust store in addition to the given certificate authority list. You will not get an accurate picture that way. Especially if the certificate was signed by a publically trusted authority.

Sidenote about file formats: We're assuming all the time that files are in PEM format. PEM files are those that include -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----

In opensslish a green mark looks like this:



client_certificate.pem: OK

If you get anything like that, you're good to go!

What if my client certificate fails the test?

When running openssl verify, you may get an error output:



C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
error 2 at 1 depth lookup: unable to get issuer certificate
error client_certificate.pem: verification failed

Assuming that you've got a good certificate file, any error means problems in the certificate authority file. This one shown here means that the first-level certificate authority (CA) is trusted, but the second one is not. OpenSSL starts counting at zero, "error X at 1 depth lookup" means that the 0 depth lookup was successful and there was an error at the next lookup.

You'll need a clean path to a root CA from the client certificate. In other words, the client certificate needs to be signed by a trusted authority and that authority's certificate also needs to be signed by a trusted authority. And so on until you get to a certificate that is signed by itself. Those are called root CAs.

In order to check what CA signs your certificate, you can use another OpenSSL command:



$ openssl x509 -in client_certificate.pem -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            ...
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
        ...
        X509v3 extensions:
            Authority Information Access: 
                CA Issuers - URI:http://secure.globalsign.com/cacert/gsrsaovsslca2018.crt
                OCSP - URI:http://ocsp.globalsign.com/gsrsaovsslca2018
            X509v3 Authority Key Identifier: 
                keyid:F8:EF:7F:F2:CD:78:67:A8:DE:6F:8F:24:8D:88:F1:87:03:02:B3:EB
            ...

And then again with the CA certificate:



$ openssl x509 -in gsrsaovsslca2018.pem -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            01:ee:5f:22:1d:fc:62:3b:d4:33:3a:85:57
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
        Subject: C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
        ...
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                F8:EF:7F:F2:CD:78:67:A8:DE:6F:8F:24:8D:88:F1:87:03:02:B3:EB
            X509v3 Authority Key Identifier: 
                keyid:8F:F0:4B:7F:A8:2E:45:24:AE:4D:50:FA:63:9A:8B:DE:E2:DD:1B:BC
            ...

Fortunately, this is a two-CA chain. And we just need one other check:



$ openssl x509 -in Root-R3.pem -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            04:00:00:00:00:01:21:58:53:08:a2
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
        Subject: OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
        ...
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                8F:F0:4B:7F:A8:2E:45:24:AE:4D:50:FA:63:9A:8B:DE:E2:DD:1B:BC
        ...

See how the X509v3 Authority Key Identifier field in one certificate corresponds to the X509v3 Subject Key Identifier in the next? And that the Issuer and Subject in the last one are the same? This means that our certificate chain is whole.

If you're lucky, the CA will provide a certificate chain file. This file includes all the CA certificates down to the root. If you're not, you may need to stitch CA files together:



$ cat gsrsaovsslca2018.pem Root-R3.pem > new_certificate_authority_list.pem

Test it again using openssl verify (just in case), ask the server team to update their file and happy SSLing!

Armazenando state Terraform no Ceph

Thiago Arrais — Thu, 27 May 2021 19:30:26 +0000

Quem tem acesso a uma instância Ceph, pode usar o backend S3 para armazenar o state Terraform. A forma de uso é basicamente a mesma que a do próprio S3. Só precisamos lembrar de configurar os seguintes argumentos:

endpoint
skip_credentials_validation
force_path_style

endpoint deve ser o nome do host que responde pela sua instância Ceph.

skip_credentials_validation controla se o backend valida credenciais contra o Amazon STS. Como você não vai conseguir que o STS valide suas credencias Ceph, vai precisar ser configurado para true.

force_path_style controla se o nome do bucket é especificado como subdomínio (meubucket.meuceph.minhaintra, por exemplo) ou como path (meuceph.minhaintra/meubucket, por exemplo). O estilo path é mais compatível com o Ceph, por isso este argumento também deve ser configurado para true

Aqui está uma versão para facilitar o copia-e-cola:

terraform {
  backend "s3" {
    bucket      = "your-bucket-name"
    key         = "a-key"
    region      = "us-east-1"
    endpoint    = "hostname.for.the.ceph.instance"
    access_key  = "your-access-key"
    secret_key  = "your-secret-key"

    skip_credentials_validation = true
    force_path_style            = true
  }
}

Storing your Terraform state in Ceph (2021)

Thiago Arrais — Thu, 27 May 2021 18:53:08 +0000

This works with Terraform 1.5.x and earlier. If you're using 1.6 or beyond, try my newer post on this matter

endpoint
skip_credentials_validation
force_path_style

endpoint should be set to the hostname where your Ceph instance responds.

skip_credentials_validation controls if the backend validates credentials against Amazon STS. Since you can't count on STS to validate your Ceph credentials, this should be set to true.

force_path_style controls if bucket names are specified in subdomains (e.g. mybucket.myceph.myintranet) or in paths (e.g. myceph.myintranet/mybucket). The path style is more compatible with Ceph, so this also should be set to true.

Here is a copy-and-paste friendly version:

terraform {
  backend "s3" {
    bucket      = "your-bucket-name"
    key         = "a-key"
    region      = "us-east-1"
    endpoint    = "hostname.for.the.ceph.instance"
    access_key  = "your-access-key"
    secret_key  = "your-secret-key"

    skip_credentials_validation = true
    force_path_style            = true
  }
}

Como verificar se um servidor vai aceitar seu certificado de cliente

Thiago Arrais — Thu, 01 Oct 2020 19:02:35 +0000

Uma forma de autenticar aplicações clientes para aplicações servidoras que está desaparecendo mas ainda é bastante comum é o uso de certificados TLS/SSL de cliente. Desse modo você pode fazer uso da infra-estrutura HTTPS existente e apenas verificar o número de série do certificado do cliente contra uma lista conhecida de aplicações autorizadas.

Isso é comumente feito em um contexto corporativo onde o processo de emissão de certificados pode ser delegado para um terceiro. Mas isso também significa que a Autoridade Certificadora pode não ser imediatamente aceita pela infra-estrutura da aplicação servidora.

Quando isso acontece, talvez o cliente não tenha 100% de certeza de que o servidor vai aceitar seu certificado. Na hora de renovar certificados — e talvez até seja necessário trocar de autoridade — a ansiedade invariavelmente ataca!

Faça isso então

O OpenSSL vai te ajudar, claro. Mas o OpenSSL não é exatamente fácil de lidar.

O comando que você precisa é openssl verify. Ele recebe como entrada uma lista de autoridades certificadoras, que vem da equipe da aplicação servidora, e um certificado de cliente, que vem da equipe da aplicação cliente.

Com esses dois arquivos em mãos, aqui está o que você vai precisar dizer no seu shell preferido:

$ openssl verify \
    -no-CApath \
    -CAfile certificate_authority_list.pem \
    client_certificate.pem

Não esqueça de incluir a flag -noCApath ou então o OpenSSL vai usar a trust store do computador além da lista de autoridades certificadores fornecida. Você não vai conseguir uma resposta precisa assim. Especialmente se o certificado foi assinado por uma autoridade publicamente reconhecida.

Nota de rodapé sobre formatos de arquivo: Estamos o tempo todo assumindo que os arquivos estão em formato PEM. Arquivos PEM são aqueles que contém linhas -----BEGIN CERTIFICATE----- e -----END CERTIFICATE-----

Em openssl-ês uma marca verde de sucesso tem essa cara:

client_certificate.pem: OK

Se você receber algo parecido com isso, pode parar por aqui que já está tudo certo!

E se meu certificado de cliente não passar no teste?

Ao rodar o openssl verify, você pode tomar um erro:

C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
error 2 at 1 depth lookup: unable to get issuer certificate
error client_certificate.pem: verification failed

Assumindo que está tudo certo com seu arquivo de certificado, qualquer erro significa problema no arquivo das autoridades certificadoras. Este que foi mostrado aqui significa que a autoridade certificadora (AC) de primeiro nível é confiável, mas a de segundo nível não. O OpenSSL inicia a contagem de zero, "error X at 1 depth lookup" significa que a busca depth 0 foi bem sucedida e houve um erro na busca seguinte.

Vamos precisar de um caminho limpo até uma AC raiz a partir do certificado do cliente. Em outras palavras, o certificado de cliente precisa ser assinado por uma autoridade confiável e o certificado dessa autoridade _também precisa ser assinado por uma autoridade confiável. E assim por adiante até chegarmos em um certificado que está assinado por si mesmo. Estas são as ACs raiz.

Para verificar que AC assina o certificado, você pode usar outro commando OpenSSL:

$ openssl x509 -in client_certificate.pem -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            ...
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
        ...
        X509v3 extensions:
            Authority Information Access: 
                CA Issuers - URI:http://secure.globalsign.com/cacert/gsrsaovsslca2018.crt
                OCSP - URI:http://ocsp.globalsign.com/gsrsaovsslca2018
            X509v3 Authority Key Identifier: 
                keyid:F8:EF:7F:F2:CD:78:67:A8:DE:6F:8F:24:8D:88:F1:87:03:02:B3:EB
            ...

E novamente com o certificado da AC:

$ openssl x509 -in gsrsaovsslca2018.pem -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            01:ee:5f:22:1d:fc:62:3b:d4:33:3a:85:57
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
        Subject: C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
        ...
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                F8:EF:7F:F2:CD:78:67:A8:DE:6F:8F:24:8D:88:F1:87:03:02:B3:EB
            X509v3 Authority Key Identifier: 
                keyid:8F:F0:4B:7F:A8:2E:45:24:AE:4D:50:FA:63:9A:8B:DE:E2:DD:1B:BC
            ...

Felizmente, essa é uma cadeia com apenas duas AC. Só precisamos de mais uma verificação:

$ openssl x509 -in Root-R3.pem -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            04:00:00:00:00:01:21:58:53:08:a2
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
        Subject: OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
        ...
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                8F:F0:4B:7F:A8:2E:45:24:AE:4D:50:FA:63:9A:8B:DE:E2:DD:1B:BC
        ...

Está vendo como o campo X509v3 Authority Key Identifier em um certificado corresponde ao campo X509v3 Subject Key Identifier do certificado seguinte? E que o Issuer e o Subject no último são os mesmos? Isso significa que nossa cadeia de certificados está íntegra.

Se você tiver sorte, a autoridade certificadora em si vai prover um arquivo de cadeia de certificados em seu site. Esse arquivo inclui todos os certificados de AC até o raiz. Se não, você vai precisar costurar arquivos de AC:

$ cat gsrsaovsslca2018.pem Root-R3.pem > new_certificate_authority_list.pem

Teste esse arquivo novo usando o openssl verify (só por precaução), peça à equipe do servidor para atualizar seu arquivo de autoridades e boa viagem com SSL!