Windows 10 docker desktop volumes

 Windows 10 docker desktop made a lot of changes between wsl and wsl2 especially how the mount works. This change created a lot of issues. Here is the main difference:

WSL:

mount point starts at this:

on drive C: /host_mnt/c

on drive D: /host_mnt/d

WSL2:

mount point starts like this

on drive C: /run/desktop/mnt/host/c

on drive D: /run/desktop/mnt/host/d

certificates key usage and extended key usage

Key usage and extended key usage

Key usage extensions define the purpose of the public key contained in a certificate. You can use them to restrict the public key to as few or as many operations as needed. For example, if you have a key used only for signing or verifying a signature, enable the digital signature and/or non-repudiation extensions. Alternatively, if a key is used only for key management, enable key encipherment.

Key usage

The following table describes the key usage extensions available for certificates created using the CA process.

Note: The digital signature and data encipherment key usage extensions are enabled by default for all Internet certificates.

Table 1. Key usage extensions

Key usage extension	Description
Digital signature	Use when the public key is used with a digital signature mechanism to support security services other than non-repudiation, certificate signing, or CRL signing. A digital signature is often used for entity authentication and data origin authentication with integrity.
Non-repudiation	Use when the public key is used to verify digital signatures used to provide a non-repudiation service. Non-repudiation protects against the signing entity falsely denying some action (excluding certificate or CRL signing).
Key encipherment	Use when a certificate will be used with a protocol that encrypts keys. An example is S/MIME enveloping, where a fast (symmetric) key is encrypted with the public key from the certificate. SSL protocol also performs key encipherment.
Data encipherment	Use when the public key is used for encrypting user data, other than cryptographic keys.
Key agreement	Use when the sender and receiver of the public key need to derive the key without using encryption. This key can then can be used to encrypt messages between the sender and receiver. Key agreement is typically used with Diffie-Hellman ciphers.
Certificate signing	Use when the subject public key is used to verify a signature on certificates. This extension can be used only in CA certificates.
CRL signing	Use when the subject public key is to verify a signature on revocation information, such as a CRL.
Encipher only	Use only when key agreement is also enabled. This enables the public key to be used only for enciphering data while performing key agreement.
Decipher only	Use only when key agreement is also enabled. This enables the public key to be used only for deciphering data while performing key agreement.

Extended key usage

Extended key usage further refines key usage extensions. An extended key is either critical or non-critical. If the extension is critical, the certificate must be used only for the indicated purpose or purposes. If the certificate is used for another purpose, it is in violation of the CA's policy.

If the extension is non-critical, it indicates the intended purpose or purposes of the key and may be used in finding the correct key/certificate of an entity that has multiple keys/certificates. The extension is then only an informational field and does not imply that the CA restricts use of the key to the purpose indicated. Nevertheless, applications that use certificates may require that a particular purpose be indicated in order for the certificate to be acceptable.

If a certificate contains both a critical key usage field and a critical extended key usage field, both fields must be processed independently, and the certificate be used only for a purpose consistent with both fields. If there is no purpose consistent with both fields, the certificate must not be used for any purpose.

Table 2. Extended key usage

Extended key	Enable for these key usage extensions
TLS Web server authentication	Digital signature, key encipherment or key agreement
TLS Web client authentication	Digital signature and/or key agreement
Sign (downloadable) executable code	Digital signature
Email protection	Digital signature, non-repudiation, and/or key encipherment or key agreement
IPSEC End System (host or router)	Digital signature and/or key encipherment or key agreement
IPSEC Tunnel	Digital signature and/or key encipherment or key agreement
IPSEC User	Digital signature and/or key encipherment or key agreement
Timestamping	Digital signature, non-repudiation.

Process when changes made to operator data type

When changes made to operator data type, one will need to run the following command:

0. setup GOPATH and GOROOT correctly first.
1. operator-sdk generate k8s
2. operator-sdk generate openapi
3. operator-sdk build <imagename>
4. operator-sdk up local

The above command is based on operator-sdk prior v0.12.0. Newer operator-sdk removed generator openapi, then you will need to download openapi generator for that.

Ingress services on IBM Cloud

TCP ports (tcp-ports)

Access an app via a non-standard TCP port.

Description
Use this annotation for an app that runs a TCP streams workload.

The ALB operates in pass-through mode and forwards traffic to back-end apps. SSL termination is not supported in this case. The TLS connection is not terminated and passes through untouched.

The below was commented by Tong

If this is indeed the case, then this should be the ideal case for Fabric node setup. It should be desirable for the traffic being untouched between the client and the Fabric nodes.

Here is another section about TLS using ALB on IBM Cloud.

Step 4: Select TLS termination

After you map your custom domain, choose whether to use TLS termination.

The ALB load balances HTTP network traffic to the apps in your cluster. To also load balance incoming HTTPS connections, you can configure the ALB to decrypt the network traffic and forward the decrypted request to the apps that are exposed in your cluster.

SSL services support (ssl-services)

Allow HTTPS requests and encrypt traffic to your upstream apps.

Description
When your Ingress resource configuration has a TLS section, the Ingress ALB can handle HTTPS-secured URL requests to your app. By default, the ALB terminates the TLS termination and decrypts the request before using the HTTP protocol to forward the traffic to your apps. If you have apps that require the HTTPS protocol and need traffic to be encrypted, use the ssl-services annotation. With the ssl-services annotation, the ALB terminates the external TLS connection, then creates a new SSL connection between the ALB and the app pod. Traffic is re-encrypted before it is sent to the upstream pods.
If your back-end app can handle TLS and you want to add additional security, you can add one-way or mutual authentication by providing a certificate that is contained in a secret.

Ingress Nginx network settings

The following network settings are for a machine which hosts nginx.

sysctl -e -w fs.file-max=6000000;  
sysctl -e -w fs.nr_open=10000000;  
sysctl -e -w net.core.rmem_max=16777216;  
sysctl -e -w net.core.wmem_max=16777216;  
sysctl -e -w net.core.rmem_default=12582912;  
sysctl -e -w net.core.wmem_default=12582912;  
sysctl -e -w net.core.optmem_max=25165824;  
sysctl -e -w net.core.netdev_max_backlog=262144;  
sysctl -e -w net.core.somaxconn=32768;  
sysctl -e -w net.core.rps_sock_flow_entries=32768;  
sysctl -e -w net.ipv4.ip_local_port_range="1025 65535";  
sysctl -e -w net.ipv4.tcp_rmem="8192 262144 16777216";  
sysctl -e -w net.ipv4.tcp_wmem="8192 262144 16777216";  
sysctl -e -w net.ipv4.udp_rmem_min=16384;  
sysctl -e -w net.ipv4.udp_wmem_min=16384;  
sysctl -e -w net.ipv4.ip_no_pmtu_disc=0;  
sysctl -e -w net.ipv4.route.flush=1;  
sysctl -e -w net.ipv4.tcp_dsack=1;  
sysctl -e -w net.ipv4.tcp_sack=1;  
sysctl -e -w net.ipv4.tcp_fack=1;  
sysctl -e -w net.ipv4.tcp_max_tw_buckets=1440000;  
sysctl -e -w net.ipv4.tcp_tw_recycle=0;  
sysctl -e -w net.ipv4.tcp_tw_reuse=1;  
sysctl -e -w net.ipv4.tcp_frto=0;  
sysctl -e -w net.ipv4.tcp_syncookies=1;  
sysctl -e -w net.ipv4.tcp_max_syn_backlog=32768;  
sysctl -e -w net.ipv4.tcp_synack_retries=2;  
sysctl -e -w net.ipv4.tcp_syn_retries=3;  
sysctl -e -w net.ipv4.tcp_fin_timeout=5;  
sysctl -e -w net.ipv4.tcp_retries2=5;  
sysctl -e -w net.ipv4.tcp_no_metrics_save=1;  
sysctl -e -w net.ipv4.tcp_moderate_rcvbuf=1;  
sysctl -e -w net.ipv4.tcp_timestamps=1;  
sysctl -e -w net.ipv4.tcp_keepalive_time=300;  
sysctl -e -w net.ipv4.tcp_keepalive_intvl=30;  
sysctl -e -w net.ipv4.tcp_keepalive_probes=6;  
sysctl -e -w net.ipv4.tcp_slow_start_after_idle=0;  
sysctl -e -w net.ipv4.tcp_window_scaling=1;  
sysctl -e -w net.ipv4.tcp_low_latency=1;  
sysctl -e -w net.ipv4.tcp_max_orphans=262144;  
sysctl -e -w net.nf_conntrack_max=9145728;  
sysctl -e -w net.netfilter.nf_conntrack_max=9145728;  
sysctl -e -w net.netfilter.nf_conntrack_tcp_timeout_time_wait=10;  
sysctl -e -w net.netfilter.nf_conntrack_tcp_timeout_fin_wait=10;  
sysctl -e -w net.netfilter.nf_conntrack_tcp_timeout_close_wait=30;  
sysctl -e -w net.netfilter.nf_conntrack_tcp_loose=1;  
sysctl -e -w net.ipv4.tcp_rfc1337=1;

Create k8s load balancer with nginx backend

Use the following yaml file to create a load balancer service on k8s. This load

balancer service will be backed by the deployment which only consists replicate

set with 2 containers using nginx.

---
apiVersion: v1
kind: Service
metadata:
  name: my-service8080
spec:
  selector:
    app: my-nginx
  ports:
    - port: 8080
      targetPort: 80
  type: LoadBalancer
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  selector:
    matchLabels:
      app: my-nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: my-nginx
    spec:
      containers:
      - name: my-nginx
        image: nginx
        ports:
        - containerPort: 80

The above picked a port 8080 to access the service, the application actually runs on port 80. In many
other applications, the port may be other numbers but the service port can be always specified to maintain a consistent endpoint for other applications.

Once the service and the deployment were created successfully, you can use the following methods to get url to hit the service.

*

   kubectl get svc my-service8080

The above should return information which contains external-ip with ports, the combination of the two will make up the url to hit the service.

**

   kubectl get svc my-service8080 -o yaml

This will return a yaml file, showing port and the hostname which will also make up the url to hit the service.

How to get kubeconfig file from a k8s cluster running on IBMCloud

Once your k8s cluster is up running, follow the below steps to get kubeconfig file.


1. install ibmcloud CLI tools if you do not already have it
   curl -sL https://ibm.biz/idt-installer | bash

2. install ibmcloud CLI ks plugin
   ibmcloud plugin install kubernetes-service

3. login to the account
   ibmcloud login -a cloud.ibm.com -r us-south --sso
   -u <id@us.ibm.com> -p <password> -g Default

this step will ask you to get a one-time passcode by providing a url you can copy and paste the url to a browser to get one-time passcode to proceed. Once you provide the passcode, it will ask you to select an account to continue.

4. retrieve the kubeconfig file, the kubeconfig file should be saved at the current directory.
   ibmcloud ks cluster config --cluster <cluster-id>

Note:

* To check what plugins are available for CLI, run the following command
ibmcloud plugin repo-plugins -r 'IBM Cloud'

** The kubeconfig should normally reference a cert .pem file, when move this kubeconfig file to another environment, the referenced pem file should also be moved.