Terraform-provider-local: local_file não deve imprimir informações confidenciais na saída se sensitive = true

Criado em 22 ago. 2018  ·  14Comentários  ·  Fonte: hashicorp/terraform-provider-local

_Esta edição foi originalmente aberta por @mtheus como hashicorp/terraform#18718. Ele foi migrado para cá como resultado da divisão do provedor . O corpo original da edição está abaixo._


Versão Terraform

Terraform v0.11.8

Arquivos de configuração do Terraform

resource "local_file" "kubeconfig" {
    sensitive = true
    content  = "${data.terraform_remote_state.kubernetes.kubeconfig}"
    filename = ".kube/config"
}

Saída de depuração

Comportamento esperado

Informações confidenciais não parecem estar na saída

Comportamento real

data.terraform_remote_state.kubernetes: Refreshing state...
local_file.kubeconfig: Creating...
  content:  "" => "\n\napiVersion: v1\nclusters:\n- cluster:\n    server: https://**<SENSIVE>**.sk1.us-east-1.eks.amazonaws.com\n    certificate-authority-data: LS0tLS1C**<SENSIVE>**\n  name: kubernetes\ncontexts:\n- context:\n    cluster: kubernetes\n    user: aws\n  name: aws\ncurrent-context: aws\nkind: Config\npreferences: {}\nusers:\n- name: aws\n  user:\n    exec:\n      apiVersion: client.authentication.k8s.io/v1alpha1\n      command: aws-iam-authenticator\n      args:\n        - \"token\"\n        - \"-i\"\n        - \"latam\"\n"
  filename: "" => ".kube/config"
local_file.kubeconfig: Creation complete after 0s (ID: 73a74cc24de6ebfe8304a9b889415884fd819390)

Passos para reproduzir

  1. terraform init
  2. terraform apply

Complementar

Deve ser aplicado em todos os componentes que imprimem saídas

Comentários muito úteis

https://github.com/terraform-providers/terraform-provider-local/releases/tag/v1.2.0 já está disponível, o que adiciona suporte para sensitive_content , então acho que esse problema pode ser encerrado.

Todos 14 comentários

O código em master implementa uma solução: sensitve_content . O que não é consistente com o resto dos recursos do terraform, mas pelo menos é uma solução.

No entanto, parece que ainda não está disponível no Terraform v0.11.10 e no provider.local v1.1.0.

Isso foi implementado em # 9 em março de 2018, mas ainda não foi lançado.

@alewando desculpe a resposta lenta aqui! A equipe principal tem trabalhado de cabeça para baixo no lançamento do terraform 0.12 e, infelizmente, algumas coisas (como este provedor!) foram negligenciadas como resultado.

Vou marcar isso para me lembrar de passar pelos PRs pendentes e publicar um release. Obrigado por trabalhar neste problema específico e obrigado pela sua paciência!

@mildwonkey Existe alguma chance de obter um corte de lançamento? Podemos fazer um fork e fazer um novo lançamento, mas requer uma carga de caldeira na orquestração do Terraform para obter um plug-in personalizado.

@mildwonkey Novamente, peço uma liberação. É uma vitória fácil e pode nos ajudar muito.

@mildwonkey Eu também acho que esse seria um recurso fantástico e estou ansioso pelo lançamento. 🙂

Para quem procura uma alternativa temporária, foi o que fiz para exportar credenciais para vários bancos de dados RDS (tenho um mapa de banco de dados/senha e uma senha mestra):

locals {
  databases = "${keys(var.shared_db_databases_passwords)}"
  manual_output = {
    endpoint  = "${module.shared_database.database_endpoint}"
    username  = "myusername"
    password  = "${var.shared_db_master_password}"
    port      = 5432
    databases = "${local.databases}"
    passwords = "${values(var.shared_db_databases_passwords)}"
  }
}

resource "null_resource" "manual_output" {
  triggers {
    databases = "${join(",", local.databases)}"
  }

  provisioner "local-exec" {
    command = "echo $DATA > manual_output.json"
    environment {
      DATA = "${jsonencode(local.manual_output)}" # Necessary to hide outputs
    }
  }
}

https://github.com/terraform-providers/terraform-provider-local/releases/tag/v1.2.0 já está disponível, o que adiciona suporte para sensitive_content , então acho que esse problema pode ser encerrado.

obrigado @invidian !

A fonte de dados local_file também deve suportar sensitive_content

@ShahNewazKhan Você está dizendo que deve haver um atributo sensitive_content para a fonte de dados local_file ? Se sim, qual seria um caso de uso para isso?

@unacceptable Imagine que você está definindo o conteúdo do recurso local_file de uma maneira diferente da criação de um recurso local_file (ou você quer apenas ler um arquivo existente). Se esse conteúdo for sensível em primeiro lugar, você precisará acessá-lo sem mostrá-lo diretamente na saída ou no tfstate.

Acho que ter essa funcionalidade faz sentido. A fonte de dados local_file poderia ter o parâmetro sensitive_filename , o que indicaria que o conteúdo deveria ser colocado na propriedade sensitive_content ao invés da propriedade content (e content_base64 ). No entanto, isso parece uma nova proposta de recurso. Talvez devêssemos criar outra questão para resolvê-lo?

Acabei de criar aqui:
https://github.com/terraform-providers/terraform-provider-local/issues/36

Acredito que a opção deveria estar presente na estrutura de dados, assim seria possível não apenas obter o sensitive_content de arquivos definidos através de recursos local_file, mas também de arquivos existentes.

Esta página foi útil?
0 / 5 - 0 avaliações