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
  }
}

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!

DEV Community: Serpro

Armazenando state Terraform no Ceph

Como verificar se um servidor vai aceitar seu certificado de cliente

Faça isso então

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