roy's questions

Implantei o servidor NFS usando o seguinte manifesto

---

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: nfs-pv-provisioning-demo
  namespace: nfs
  labels:
    role: nfs-server
spec:
  storageClassName: aws-gp3
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

---

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-server
  namespace: nfs
spec:
  replicas: 1
  selector:
    matchLabels:
      role: nfs-server
  template:
    metadata:
      labels:
        role: nfs-server
    spec:
      containers:
      - name: nfs-server
        image: registry.k8s.io/volume-nfs:0.8
        ports:
          - name: nfs
            containerPort: 2049
          - name: mountd
            containerPort: 20048
          - name: rpcbind
            containerPort: 111
        securityContext:
          privileged: true
        volumeMounts:
          - mountPath: /exports
            name: mypvc
      volumes:
        - name: mypvc
          persistentVolumeClaim:
            claimName: nfs-pv-provisioning-demo

---

kind: Service
apiVersion: v1
metadata:
  name: nfs-server
  namespace: nfs
spec:
  ports:
    - name: nfs
      port: 2049
    - name: mountd
      port: 20048
    - name: rpcbind
      port: 111
  selector:
    role: nfs-server

---

Mas quando eu uso nfs-server.nfs.svc.cluster.localo nome do servidor, não consegui resolver. Funcionou quando eu uso Cluster IP para endpoint de serviço.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs
  namespace: nfs
spec:
  capacity:
    storage: 1Mi
  accessModes:
    - ReadWriteMany
  nfs:
    server: nfs-server.nfs.svc.cluster.local
    # server: 172.20.144.30
    path: "/"
  mountOptions:
    - nfsvers=4.2

Alguma idéia do que há de errado com essa configuração?

Eu tenho trabalhando Nginx com autenticação TLS com a seguinte configuração. Todas as solicitações com certificados de cliente válidos serão encerradas no Nginx e a solicitação será encaminhada para o aplicativo de back-end.

    upstream app {
        server app:8080;
    }

    server {
        listen                 443 ssl;
        server_name            localhost;
        ssl_certificate        /etc/ssl/cert_example_com.crt;
        ssl_certificate_key    /etc/ssl/cert_example_com.key;
        ssl_client_certificate /etc/ssl/ca.crt;
        ssl_protocols          TLSv1.2 TLSv1.3;
        ssl_ciphers            HIGH:!aNULL:!MD5;
        ssl_verify_client      on;

        location / {
                proxy_pass         http://app;
                proxy_set_header   X-Forwarded-For $remote_addr;
                proxy_http_version 1.1;
                proxy_set_header   Upgrade $http_upgrade;
                proxy_set_header   Connection 'upgrade';
                proxy_set_header   Host $host;
                proxy_cache_bypass $http_upgrade;
        }
    }

Com essa configuração, quero que o Nginx autentique apenas determinados certificados de cliente. Isso ocorre porque estou usando o Private RootCA para gerar certificados Tipo A e certificados Tipo B. Os certificados do tipo A são usados ​​com MQTT para autenticação e os certificados do tipo B são usados ​​para HTTPSautenticação do Nginx ( ).

certificado de cliente (Tipo A) para MQTT será exclusivo para cada cliente <UUID>.example.com. o certificado do cliente (Tipo B) para Nginx terá nome (DN) base.example.come o certificado será compartilhado entre vários clientes. Além disso, haverá um número limitado de certificados Tipo B ativos ao mesmo tempo com o mesmo nome (DN) base.example.come ID de certificado diferente.

qualquer ajuda sobre isso como eu posso conseguir isso?

Eu tenho o Nginx & App rodando em container (Kubernetes). Usando o ponto de entrada NginX para handshake TLS com a seguinte configuração

    upstream app {
        server app:8200;
    }

    server {
        listen                  443 ssl;
        server_name             localhost;
        ssl_certificate         /etc/ssl/util_example_com.crt;
        ssl_certificate_key     /etc/ssl/util_example_com.key;
        ssl_client_certificate  /etc/ssl/ca.crt;
        ssl_protocols           TLSv1.2 TLSv1.3;
        ssl_ciphers             HIGH:!aNULL:!MD5;
        ssl_verify_client       on;

        location / {
                proxy_pass         http://app;
                proxy_read_timeout 180;
                proxy_set_header   X-Forwarded-For $remote_addr;
                proxy_http_version 1.1;
                proxy_set_header   Upgrade $http_upgrade;
                proxy_set_header   Connection 'upgrade';
                proxy_set_header   Host $host;
                proxy_cache_bypass $http_upgrade;
        }

    }

Eu posso curl http://app:8080/generatordo Nginx Container. Mas quando faço o mesmo no endpoint público com curl ( https://util.example.com/generator) que atinge o Nginx primeiro, recebo o 504 Gateway Time-outseguinte erro no Nginx

2021/05/04 21:54:50 [error] 21#21: *1 upstream timed out (110: Connection timed out) while connecting to upstream, client: 10.2.16.183, server: localhost, request: "POST /generator HTTP/1.1", upstream: "http://172.20.154.113:8200/generator", host: "util.example.com"

qualquer ajuda sobre, o que está acontecendo aqui.

Desejo configurar a CA privada para serviços internos usando o Vault (HashiCorp). Estou gerando o certificado de CA raiz e CA intermediária fora do Vault. O Vault gerará um certificado de curta duração (30 dias) com base na solicitação.

Eu segui este guia https://jamielinux.com/docs/openssl-certificate-authority/introduction.html e gerei Root CA Certificate example.com& dev.example.com, mas preciso de um certificado intermediário curinga *.dev.example.compara o Vault gerar mais certificados de subdomínio one.dev.example.comcomo two.dev.example.com?

Agradeço qualquer ajuda nisto ?

Eu tenho a configuração do cofre em execução no contêiner para o PKI Secrets Engine e gostaria de adicionar suporte OCSP para o aplicativo verificar se o certificado não foi revogado. Não encontrei nenhuma explicação sobre como configurar o OCSP para o cofre, também não esclareceu as informações em nenhum dos blogs.

Na minha configuração, configurei o seguinte para CRL

vault write pki/config/urls \
        issuing_certificates="http://127.0.0.1:8200/v1/pki/ca" \
        crl_distribution_points="http://127.0.0.1:8200/v1/pki/crl"

Mas nada além disso para OCSP

Preciso configurar um serviço separado para OSCP ou o Vault pode lidar com isso sozinho?

Qualquer ajuda sobre isso para entender OCSP para Vault seria apreciada?

Eu tenho o ponto de extremidade TCP para um serviço em execução com TLScertificado (autoassinado). Para testar esse endpoint eu uso openssl s_client -connect service.domain.com:5050que não imprime CONNECTED(00000006)mais nada.

Eu tenho cert & key para o certificado autoassinado que estou usando para este ponto de extremidade. Como posso usar a chave com o opensslcomando acima?

Se isso não for possível openssl, de que outra maneira posso testar isso?

Eu tenho o seguinte StorageClassdefinido para aws ekscluster (3 nós)

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: aws-gp2
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
  zones: us-west-2a, us-west-2b, us-west-2c, us-west-2d
  fsType: ext4
reclaimPolicy: Retain
allowVolumeExpansion: true

e ter eksnós em execução em us-west-2a, us-west-2b, us-west-2czonas.

Quando estou tentando implantar mysqlcom volume persistente dinâmico

---

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: mysql-pv-claim
  namespace: default
  labels:
    app: mysql
    env: prod
spec:
  storageClassName: aws-gp2
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi

---

kind: Deployment
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
metadata:
  name: mysql
  namespace: default
  labels:
    app: mysql
    env: prod
spec:
  selector:
    matchLabels:
      app: mysql
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - image: mysql:5.6
        name: mysql
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-secret
              key: root-password
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /var/lib/mysql
      volumes:
      - name: mysql-persistent-storage
        persistentVolumeClaim:
          claimName: mysql-pv-claim

Mas o pod não vai além do Pendingstatus.

O log de eventos do pod diz:

Events:
  Type     Reason            Age               From               Message
  ----     ------            ----              ----               -------
  Warning  FailedScheduling  8s (x7 over 20s)  default-scheduler  pod has unbound immediate PersistentVolumeClaims (repeated 3 times)
  Warning  FailedScheduling  8s (x2 over 8s)   default-scheduler  0/3 nodes are available: 3 node(s) had volume node affinity conflict.

Não estou entendendo por que o pod não consegue montar o PVC.

Eu adicionei mais 1 nó ao cluster eks, para que todos os 4 nós possam abranger 4 az e, em seguida, reimplante mysqle funcionou. Ainda não sei qual foi o verdadeiro problema.

Eu queria saber se a Verizon pode encerrar sua VPN para AWS VPC?

Nossa configuração existente tem o Cisco Router (CSR1000V) em execução na instância do EC2 e o Verizon VPN é encerrado no IP público da instância do EC2. É assim que o tráfego da Verizon entra na AWS VPC.

Estou tentando configurar o servidor NTP local para alguns testes. Eu instalei o NTP Ubuntu 18.04e comentei o bloco de pool de servidores no arquivo de configuração

Aqui está a configuração completa:

driftfile /var/lib/ntp/ntp.drift

leapfile /usr/share/zoneinfo/leap-seconds.list

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

restrict -4 default kod notrap nomodify nopeer noquery limited
restrict -6 default kod notrap nomodify nopeer noquery limited

restrict 127.0.0.1
restrict ::1

restrict source notrap nomodify noquery

restrict 10.24.0.0 mask 255.255.0.0 notrust

server 127.127.1.0
fudge 127.127.1.0 stratum 10

Usei este comando para definir a hora que eu querosudo timedatectl set-time "2013-06-02 23:26:00"

Eu também tentei ver se o serviço é ntp o serviço está sendo executado pelo sudo systemctl status ntp.serviceque está sendo executado, mas quando grepped na porta 123não encontrei nada em execução. Encontrado comps

ubuntu@ntp:~$ ps auxww | grep '[n]tp'
ntp      13517  0.0  0.8 103212  4136 ?        Ssl  Jun02   0:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 111:115

Quando o cliente tenta obter o tempo do NTP em execução neste servidor, ele atinge o tempo limite. Também não vejo nenhuma mensagem em/var/log/syslog

Mais informações :

ubuntu@ntp:~$ ps auxww | grep '[n]tp'
ntp        807  0.0  0.7 103212  3480 ?        Ssl  Jan28   0:02 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 111:115

ubuntu@ntp:~$ ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*127.127.1.0     .LOCL.          10 l    2   64  377    0.000    0.000   0.000

ubuntu@ntp:~$ ntpq -c rv
associd=0 status=0515 leap_none, sync_local, 1 event, clock_sync,
version="ntpd [email protected] (1)", processor="x86_64",
system="Linux/4.15.0-1019-aws", leap=00, stratum=11, precision=-24,
rootdelay=0.000, rootdisp=11.016, refid=LOCAL(0),
reftime=de1977a0.2605c5ad  Mon, Jan 29 2018  5:36:16.148,
clock=de1977a6.758ae7fc  Mon, Jan 29 2018  5:36:22.459, peer=57525, tc=6,
mintc=3, offset=0.000000, frequency=0.000, sys_jitter=0.000000,
clk_jitter=0.000, clk_wander=0.000, tai=37, leapsec=201701010000,
expire=201812280000

Eu tentei este script para obter o tempo do servidor NTP real, onde funcionou, mas não no NTP autônomo.

O que estou perdendo aqui?