Info locales

🌞 08:24 | 13:38 | 18:50

⛅ +7jours ⇒ -9min -10min = -19 min

The Most AMAZING commercial ever!!! - Coleman Sweeney - YouTube

Le Hollandais Volants -- Liens

« even an asshole can save lives »


— (permalink)

FixPhrase

Le Hollandais Volants -- Liens

Un système GPS pour transmettre les coordonnées via des mots de la langue courante.

Via : https://sebsauvage.net/links/?3sbQ3A

Le code fait 200 lignes, mais y a un dictionnaire de 7 000 mots : Le code source : https://source.netsyms.com/Netsyms/fixphrase.com/src/branch/master/FixPhrase.lib.php

Donc a priori, il faudrait un dico français et hop, on a la version française.

La difficulté est d’avoir des mots suffisamment différents entre-eux (un peu comme l’alphabet radio où les mots sont très soigneusement choisis pour éviter les collisions quand on les prononce transmet sur une ligne téléphone merdique).

Les dictionnaires Hunspell (listes de mots utilisés par tous les correcteurs d’orthographe) comportent environ 50 000 à 150 000 mots selon les langues. Ça peut-être un bon début.

Il suffit d’éliminer :
- les mots trop courts (<=3 lettres)
- trop longs (>12 lettres)
- ainsi que les pluriels (<mot1>+s == <mot2> ? on vire le <mot2>).
- les mots trop compliqués (si on garde « feldspath », « ouananiche » ou « tétraktys », certains vont se planter c’est sûr — oui ce sont de vrais mots)

Ensuite pour les ressemblances entre les mots ou les homonymes, on peut filtrer en utilisant la clé soundex d’un mot (d’empreinte phonétique — faut voir s’il existe en soundex-français).

Puis on réduit la liste des mots : en prenant 1 sur 2, puis, puis en refaisant un soundex() plus large. Au final, on filtre peu à peu jusqu’à obtenir 7k mots.

Yapluka implémenter tout ça.


… allo ?


— (permalink)

OpenShift 4 Resources Configuration: Methodology and Tools

OpenShift blog

 

Opening introduction

Capacity planning is more an art than a science: While performance tuning is a process to optimize the existing systems to achieve higher performance, capacity planning determines how a system needs to be configured to behave in the most advantageous way, using the current performance as a baseline.

It is difficult to predict the amount of resources that production OpenShift objects may need to function optimally. OpenShift typically runs a varied number of resources set under different profiles in a multipurpose environment.

It is the design team’s goal to anticipate the required total capacity by ensuring to meet the installation prerequisites and compute the necessary resources in case of a cloud installation, but it is the developer team that will know the exact resource expectations of a service implementation.

The good news is that there are some tools that can help figure out the right numbers in a pre-production phase. In this introductive blog article, we will provide some high-level tips for general configuration recommendations and discuss these tools.

Reviewing the OpenShift core tools

To keep control of the availability of resources across an OpenShift cluster, an administrator can use some core mechanisms.

ResourceQuotas are namespace-wide restrictions that force all the pods in a namespace not to exceed the assigned quota or hog a namespace's resources, irrespective of which node they are scheduled on, including storage and objects count. So you can specify a hard limit of 1 core, 4GiB of RAM, and 10 Pods maximum:

spec:
hard:
  cpu: 1
  memory: 4Gi
  count/pods: 10

LimitRanges are similar to ResourceQuota except that they are resource-specific: Pods and other objects usage can be limited by cluster administrators who apply the LimitRanges to ensure the optimal use of resources, by defining a range of available compute and memory resources:

spec:
limits:
  - type: "Container"
    max:
      cpu: "2"
      memory: "1Gi"
    min:
      cpu: "0.7"
      memory: "4Mi"
    defaults:
      cpu: "1.3"
      memory: "100Mi"

PriorityClasses allow to define Pods priority, and this is instead an OpenShift scheduler thing. The priority indicates the importance of a pod relative to other pods. If a PodA cannot be scheduled, the scheduler attempts to evict lower priority pods to allow PodA to be scheduled. You set a priority class with a mandatory field value (the bigger, the higher the priority is):

oc create priorityclass high-priority --value=1000 --description="high priority"

A good use of PriorityClass is to reserve larger priority numbers to critical system pods that should not usually be preempted or evicted. A potential abuse is that users can try to set the highest possible priority for their pods. To prevent that, ResourceQuota supports PriorityClass, allowing it to unmatch the quota if the set value is too high.

Kubernetes QoS

Also, Kubernetes defines QoS (Quality of Service): When a pod is created, it get assigned a QoS class, a property derived from the pod resource limits configuration:

  • BestEffort: No resource limits defined - A BestEffort CPU container will be able to consume as much CPU as is available on a node with the lowest priority.
  • Burstable: Only memory limits are set - Is guaranteed to get the minimum amount of CPU requested, but it may or may not get additional CPU time. Excess CPU resources are distributed based on the amount requested across all containers on the node.
  • Guaranteed: Both memory and CPU limits are set - It is guaranteed to get the amount requested and no more even if there are additional CPU cycles available

For best hardware use in a non-production cluster, which is more dynamic and creates and destroys objects at a high rate, it may be a good idea to mainly use BestEffort and Burstable. On production clusters, where we want things to be stable and predictable, it is better to orient the choice on the use of mostly Guaranteed type and some Burstable.

Don't touch the OpenShift core

On OpenShift core components, you do not want to apply quotas.

The risk is to severely impact important functionalities. Suppose you set ResourceQuota on the Etcd namespace. In case of a spike in the amount of data handled by Etcd, the applied constraints may be not enough to sustain that spike, and Etcd might exhaust its memory and kill itself, deteriorating the cluster health.

Other vendors plug-ins and integrations

Do the vendors of additional components such as monitoring, logging, or others have resource requirements/documentation? Typically, no quotas and limits should be modified here, too, in case you have to consult the vendor.

To overcommit or not to overcommit?

Overcommitting is the practice to present to the hosted applications more CPU and memory resources than there are physically: This allows increasing the density of workloads running on the platform but will turn down individual applications performances.

In case of OpenShift on OpenStack, for instance, when looking to implement overcommit, consider the complexity of the two systems. Both can manage resources through detailed tuning. And you have probably had success tuning each independently. But when placing them together, you should tune based on the complete stack, not each layer in isolation.

In this case, both OpenShift and OpenStack are capable of implementing complex resource management. If we allow them both to do it at the same time, we need to ensure they do not conflict with each other. So if you do choose to implement resource management at both levels, be sure you understand exactly how that will interact. This can be hard, is often time-consuming and error-prone, and consistently needs review.

Instead, it is easier to overcommit on only one level and ideally the one closer to the user. And in this case, that is OpenShift, which has complex resource management already built in.

But for this to work, it needs a consistent set of resources presented to it. If OpenStack is constantly adjusting memory and resources, how will OpenShift be able to accurately adjust for it? It is like two people trying to drive the same car in different directions. It is often better to trust OpenShift to work its magic based on consistent resources and avoid having the resource rug pulled out from under it by OpenStack trying to manage this as well.

We are not saying you cannot overcommit, just that if you do so, you will need to have a very detailed knowledge of your workloads, one which you probably cannot obtain for everything you have on your cloud. And implementing overcommit in one place on this stack will make troubleshooting resource issues easier and quicker, while likely reducing them in the first place.

The Reference Architecture of OpenShift on OpenStack may include further material on this topic, and more is to come.

Applications on OpenShift

To define the required resources of applications running on OpenShift, the base idea is to run a series of stress tests to measure the amount of resources and determine what the baseline will be, before moving to specific tunings (such as on the JVM or the single pods allocations).

Admins and developers will be able to get an overview of the resource usage requests for their application by going to the OpenShift Web Console → Monitoring section. Here is the historical consumption for both CPU and memory: For all apps in the project aggregated, or separately.

The Monitoring tab in the Developer view in Consnole

Figure1: The Monitoring tab in the Developer view in Console

Resources limits and compressibility

Regarding how to configure ResourceQuota, there are few to no issues with setting a CPU limit incredibly high or not setting a CPU limit at all: CPU is a compressible resource. This means that if your app arrives at a point where it hits the CPU limits, Kubernetes will just begin throttling your containers. If you set a hard limit, instead the CPU will be artificially restricted, giving your app potentially worse performance. However, it will not be terminated or evicted. You can make use of the Readiness or Liveness health probes to check if performance is impacted.

The situation is complicated if more applications simultaneously start creating some resource consumption peaks. In this case, you can use the Kubernetes QoS again, as explained in a previous section, prioritizing Guaranteed policies in production and Burstable in test environments, as explained in the Kubernetes QoS section above.

In some specific situations, however, setting CPU hard limits may be a good choice, for example when you want to:

- Achieve predictable performances rather than the best performances

- Protect deployments from other greedy containers

- Avoid resource starvation when other concurrent applications may peak their resources consumption while they are starting up

- Keep overcommitting under control

Instead, memory is an incompressible resource: If allocation is too low, this will invoke the language memory systems such as the garbage collection or, worse, the application may go to Out Of Memory and the pods will be killed by the Linux kernel. Memory optimization is a very vast topic and requires mixing best programming practices, stress tests, and using the right tools.

We willl see a couple of these tools in the next two sections that, in conjunction with the OpenShift monitoring stack, can help you to determine the right amount of memory to assign to your applications.

So the key takeaway when doing capacity planning of containerized apps is that lack of compressible resources (such as CPU or networking) will throttle the resources themselves but will not kill pods, while unhandleable pressure on incompressible resources (such as memory) may kill your pods.

Java on OpenShift

In the case of Java programs, it is known that the longer they run, the better they perform. Said the other way, they consume much more resources during their startup. So, when defining baselines, it might be useful to keep this in mind and account this initial period as a "warm-up" period where you make no or little measurements.

Teams want to run a series of tests to benchmark the app performance before deciding whether additional tuning is needed and, in case, consider tuning the JVM. For this we provide OpenJDK specific documentation and a Red Hat Lab: Tick with yes the "Is the application running on OpenShift?" option and fill the fields to retrieve the recommended settings on this page: https://access.redhat.com/labs/jvmconfig/

Figure 2: JVM Options Configuration Lab

The choice of a collector is not easy and would require a very long discussion. Shortly, with the CMS collector being deprecated soon, and Shanondoah being still experimental, the choice restricts mostly to the G1, the default and best collector in the majority of cases, and Parallel, which may make sense in case of hyperthreaded containers.

You may also want to consult the Universal Base Images OpenJDK runtime images page for more info on how Red Hat packs and optimizes the OpenJDK container image.

The VerticalPodAutoscaler

In the process of defining the baselines and succeeding in capacity planning, you can also benefit from the Vertical Pod Autoscaler, now a generally available feature in OpenShift 4.8.

The VPA monitors the historical trend of resources consumed by pods during time and can automatically tune the pods limits or, in Off mode, just give some recommendations so that they may be applied manually.

In Auto mode, the VPA applies the computed settings automatically throughout the pod lifetime: The VPA rolls out again the pods in the project that are out of alignment with its recommendations so the limits are applied in their configuration:

Figure3: The VerticalPodAutoscaler in action

To give an example, let's imagine you have deployed the "Get started with Spring" tutorial in the spring-one namespace and want to get some LimitRange recommendations to understand how it behaves.

You begin by installing the VerticalPodAutoscaler from the Operators → OperatorHub in its openshift-vertical-pod-autoscaler system namespace. Then, you create a VPA object in the spring-one namespace, where you want to observe the deployment named rest-http-example. You don't want the VPA to take control over your pods, so you just specify the "Off" updateMode:

oc create -f - << EOF
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
name: spring-recommender
namespace: spring-one
spec:
targetRef:
  apiVersion: "apps/v1"
  kind:       Deployment
  name:       rest-http-example
updatePolicy:
  updateMode: "Off"
EOF

At this point, you simulate typical workloads and finally output what is the range of values that the VPA suggests, by printing the VPA content and examining the target section that contains recommended values:

$ oc -n spring-one get vpa spring-recommender --output json | jq .status.recommendation                ~
{
"containerRecommendations": [
  {
    "containerName": "rest-http-example",
    "lowerBound": {
      "cpu": "25m",
      "memory": "262144k"
    },
    "target": {
      "cpu": "25m",
      "memory": "262144k"
    },
    ...
  }
]
}

Scheduler settings

There is also great control on the scheduling settings for capacity optimization to take into account. Users can decide where to deploy Pods with NodeSelector, define Scheduler profiles for a uniform cluster usage, use PodPriority, and tune it with a minimum number of available replicas with PodDisruptionBudget. Ops can observe the availability of resources with the integrated OpenShift Monitoring stack or with the Cluster Capacity Tool, an upstream project that may help measuring and simulating cluster capacity availability either with a local binary or with ad-hoc pods.

Summary

In this blog article, we reviewed the available core tools for limiting and configuring applications resources, clarified the right OpenShift core settings, and lightly covered the tricky topic of platform overcommit. We then reviewed what to do to start with a capacity planning process for applications by suggesting some methodology and tools, notably the Java Virtual Machine lab and the Virtual Pod Autoscaler.

Happy tuning.

Pyrates

Liens SebSauvage
Un site pédagogique pour apprendre les bases de Python sous forme de jeu: notion de variables, exécution conditionnelle, boucles.
(Permalink)

FixPhrase

Liens SebSauvage
Transmettre des coordonnées GPS, c'est fastidieux et sujet à erreur. Cet algorithme peut convertir des coordonnées GPS en 4 mots. Par exemple, au lieu de transmettre (48.5819, 7.7511), je peux transmettre "crease marshy strike unfunded".
Contrairement à son concurrent "What3Words", FixPhrase est un logiciel libre et à sources ouverts. Par contre on retombe sur le même problème: C'est pensé pour des anglophones.
(Permalink)

Un commun numérique fête ses 25 ans : Internet Archive – Framablog

Liens SebSauvage
L'Internet Archive est probablement l'un des plus importants projets technologiques et humains.
(Permalink)

La laïcité, c'est pas ce que vous croivez

Liens SebSauvage
Après avoir (encore) entendu Zorglub déblatérer lors de sa mise en scène pitoyable, j'ai besoin de rappeller une évidence: Les mots sont détournés de leur signification pour favoriser la pensée fasciste.
Quand il crache sur l'expression public de signes religieux parce que "C'est ça la laïcité", c'est un mensonge. Et il le sait. C'est un détournement de sens du mot "laïcité".
(https://www.larousse.fr/dictionnaires/francais/la%c3%afcit%c3%a9/45938)

La laïcité, c'est la séparation de l'église et de l'état. C'est:
- interdire à la hiérarchie religieuse d'exercer du pouvoir au sein de l'état.
- traiter tout le monde - quelle que soit sa religion - sans discrimination au niveau des administrations.
- interdire les signes religieux pour les agents de l'état dans l'exercice de leurs fonctions.
- Pas d'enseignement religieux à l'école.

Dieu sait (haha) que je suis CONTRE les religions (je pense qu'elles sont globablement nuisibles à l'humanité), mais la liberté d'exprimer sa religion dans l'espace public (par des symboles, vêtements ou autres) est inscrite dans la déclaration des droits de l'homme. Ceux qui luttent contre le voile dans l'espace public sont donc des ENNEMIS de la liberté, des ennemis des droits de l'homme. OUI, les gens ont le DROIT de montrer publiquement, ostensiblement et de manière personnelle des signes de leur religion dans l'espace public sans violer ne serait-ce qu'une seconde la laïcité si chère à la France. La liberté de culte et son expression dans l'espace public sont garanties par la loi.

Et c'est sans compter qu'il n'y a pas si longtemps, les femmes en France ne pouvaient sortir dans la rue sans un foulard sur la tête À CAUSE de la religion catholique. Paille, poutre, tout ça...
Quand j'entends « Le voile ne fait pas partie de nos valeurs judéo-chrétienne, c'est pas notre France. », je pouffe:
https://sebsauvage.net/galerie/photos/Bordel/mili/voile1.jpg
https://sebsauvage.net/galerie/photos/Bordel/mili/voile2.jpg
https://sebsauvage.net/galerie/photos/Bordel/mili/voile3.jpg
https://sebsauvage.net/galerie/photos/Bordel/mili/voile4.jpg

Et quand on crie au loup pour la laïcité dans l'éducation dès qu'il s'agit des Musulmans, rappellons que:
- l'état finance des écoles catholiques privées (dans lesquelles, oui, il y a de l'enseignement religieux).
- qu'il y a encore de l'enseignement religieux (optionnel) en Alsace au sein de l'éducation nationale.
- qu'il y a des signes religieux dans absolument tous les villages (croix partout)
- nos enfants mangent du poisson le vendredi à cause des coutumes catholiques.
Encore une fois: Paille, poutre, tout ça...
(Permalink)

Rhône : Le chasseur rate sa cible et dézingue un câble d'électricité

Le Hollandais Volants -- Liens

Ils tuent des gens dans leur jardin, leur voiture et même jusque dans leur salon.
Ils déversent tous les ans, en Europe, environ 20 000 tonnes de plomb dans la nature.
Ils privatisent la forêt, les chemins, la nature, chaque week-end.

Désormais, ils coupent aussi les lignes électriques à coup de fusil.

On va les laisser faire longtemps encore ?


— (permalink)

Guy Applies To 60 Places That Said They Were Hiring, Only Gets 1 Interview, Shares How Something Doesn't Add Up | Bored Panda

Le Hollandais Volants -- Liens

Les entreprises postent des « offres » d’emploi partout mais ne répondent pas plus qu’avant à ceux qui soumettent leur CV.

Du coup, du côté des entreprises, ils se plaignent que plus personne ne veut bosser, alors que c’est faux.

Les gens veulent bosser (en tout cas la majorité), c’est juste qu’ils ne veulent pas bosser pour rien dans des conditions de merde.

Pour info : fouillez les offres d’emploi sur le net, et regardez combien y mettent le montant du salaire proposé.
On doit être à quoi ? 5 % des offres ?
Alors que c’est sûrement l’information la plus importante, avec le nom du post occupé dans la boîte.

----

D’une façon générale, les fiches de posts sont mal foutues.
On n’a pas forcément besoin de savoir que l’entreprise investie 3 millions au Burkina Faso ou qu’elle est présent dans 43 pays, ou encore que c’est une #startup #innovante #digitale avec une salle de billard. En tout cas, moi, je m’en fiche.

À la limite, c’est quelque chose à balancer lors de l’entretien ou sur le site internet.

Ce que je veux voir :
- intitulé du poste (« boucher / charcutier », « facteur », « soudeur », …)
- nom de la boîte
- domaine d’activité (pharma, aéro, auto, alimentaire… ça suffit à n’importe qui connaissant son métier de se faire une idée, en fonction de l’intitulé du poste. Je n’ai pas besoin qu’on m’explique mon métier)
- le salaire (avec une fourchette réduite : mettre "entre 1000 et 4000 €, c’est stupide)
- où (adresse exacte) ? quand (dates de début et horraires) ?
- type de contrat.

Voilà.


— (permalink)

External Secrets with Hashicorp Vault

OpenShift blog

 

Background

I’ve been spending a fair amount of time researching secrets management with OpenShift. The interest started with the IBM Vault Plugin for Argo CD, which allows us to store placeholders for Secrets in Git. But, when used with the OpenShift GitOps operator, a fair amount of configuration and maintenance is required. I asked other co-workers to join in a roundtable to discuss secrets management and surrounding tooling. Among the leading interest in this space was Kubernetes External Secrets (External Secrets) and so the journey began to start implementing each tool and comparing these not only at a platform level, but also with consideration for GitOps and Argo CD. At no point is a single solution being proposed as the best path forward for every use case. Development and operation requirements must be considered along with the pros and cons of each tool in mind. This proof of concept is based on a Hashicorp Vault back end, as I have utilized this tool with several customers recently.

What are External Secrets?

External Secrets extends the Kubernetes API vi an ExternalSecrets object + a controller. In short, the ExternalSecret object declares how and where to fetch the secret data from the external source, and in turn, the controller converts that resource into a secret in the namespace for which the ExternalSecret is created. In the case of GitOps, utilizing external-secrets allows you to store the ExternalSecret in Git without exposing the sensitive asset in Git or in the GitOps tool (Argo, Flux, etc). In the case of application consumption of secrets, pods are still able to utilize secrets just as they normally would. The External Secrets controller creates the secret based on the ExternalSecrets manifest. Everybody knows the rules... NO SECRETS IN GIT! Utilizing External Secrets allows us to abide by by these rules.

Assumptions for this Demo

  • Access to a working OpenShift cluster. If a Cluster is not available, Code Ready Containers can be utilized for this exercise.
  • A Hashicorp Vault implementation. In the demo, dev mode is utilized which deploys a single pod instance. "Dev mode" is not meant for production and should not be run outside of sandbox or development environment
  • A secret to store.

Deploying External Secrets is an incredibly simple process consisting of installing the tooling and creating your ExternalSecret manifest based on secrets management back end in use. Secrets management backends are not limited to Hashicorp Vault as External Secrets supports a number of providers. A full list of supported backends can be found here

A large portion of this demo will revolve around configuring Vault. We will touch on the basic concepts, but not dive into the advanced configuration options available.

Assuming an OpenShift cluster or CRC is available and you are currently logged in, create 2 projects: one for external secrets and one for the dev vault instance. We will also add Helm repositories for each of the two tools.

Lets Create the projects and add the Helm repositories

oc new-project external-secrets
helm repo add external-secrets https://external-secrets.github.io/kubernetes-external-secrets/
oc new-project vault
helm repo add hashicorp https://helm.releases.hashicorp.com

Configuring Vault

When utilizing Vault as a secrets manager back end to store secrets, we can consider the steps below for a working implementation. Sealing and unsealing the Vault is out of scope for the demo as the Vault will be unsealed when installed using "Dev Mode". We are installing Vault from a Helm chart without the use of the Vault Agent Injector. I’m approaching this to concentrate on the strengths of External Secrets and the ability to allow the tooling to handle secrets without additional injection. Only a single vault-0 pod will start as an ephemeral Vault instance.

Change into the vault project and deploy Vault using Helm.

oc project vault
helm upgrade -i -n vault vault hashicorp/vault --set "global.openshift=true" --set "server.dev.enabled=true" --set="injector.enabled=false" --set="server.image.repository=docker.io/hashicorp/vault"
NAME: vault
LAST DEPLOYED: Thu Sep 16 12:10:00 2021
NAMESPACE: vault
STATUS: deployed
REVISION: 1
NOTES:
Thank you for installing HashiCorp Vault!

Now that you have deployed Vault, you should look over the docs on using Vault with Kubernetes available here:https://www.vaultproject.io/docs/

Configuration

We begin our journey with Vault by first enabling an authentication method and later, we will configure namespace and service account access. Because we are using a Dev environment, we will implement these configurations at the pod level utilizing oc rsh to access our Vault pod.

In particular, following steps will be performed:

  • Enable Kubernetes authentication.
  • Configure authentication to utilize the pod service account token and cert of the k8s host.
  • Create a secret.
  • Create a Vault Policy to access the secret (or secret path.)
  • Create a role to associate with the policy created earlier.

Step 0. Execute a remote shell session (rsh) to the Vault pod

oc rsh vault-0

Step 1. Enable Kubernetes Auth (from within the pod)

vault auth enable kubernetes

Step 2. Configure our authentication to utilize the service account token mounted in the pod and certificate of the Kubernetes cluster.

vault write auth/kubernetes/config token_reviewer_jwt="$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" kubernetes_host="https://$KUBERNETES_PORT_443_TCP_ADDR:443" kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt issuer=https://kubernetes.default.svc

Step 3. We will utilize the KV secrets engine and create a key:value pair password to store in our Vault.

vault kv put secret/vault-demo-secret1 username="phil" password="notverysecure"

Step 4. Create a policy (an hcl or JSON file) which defines the access allowed to the secrets path.

vault policy write pmodemo - << EOF
path "secret/data/vault-demo-secret1"
{ capabilities = ["read"]
}
EOF

Step 5. Create roles to associate the namespace and service account with the policy which was created earlier. Two roles will be created: one for the external secrets namespace and the other for testing later on. It is important to note that you will need to set the bound_service_account_names and the service_account_namespaces to those associated with the Deployment (external-secrets) or StatefulSet (vault).

vault write auth/kubernetes/role/pmodemo1 bound_service_account_names=vault bound_service_account_namespaces=vault policies=pmodemo ttl=60m
vault write auth/kubernetes/role/pmodemo bound_service_account_names=external-secrets-kubernetes-external-secrets bound_service_account_namespaces=external-secrets policies=pmodemo ttl=60m

At this point, we've enabled Kubernetes authentication, configured our auth, created a secret, policy, and role, and we should now be able to interact with the Vault API. Let's test this:

From the pod that will be accessing Vault, export the Service Account token. It is important to note here that if your pod is not mounting a service account token (automountServiceAccountToken: false), you will not be able to utilize the Kubernetes Auth method.

OCP_TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)

Now, lets make a request to Vault to validate out setup:

wget --no-check-certificate -q -O- --post-data '{"jwt": "'"$OCP_TOKEN"'", "role": "pmodemo1"}' http://vault:8200/v1/auth/kubernetes/login
{"request_id":"5e833fc7-4f53-f7dc-edfe-2257a42793d1","lease_id":"","renewable":false,"lease_duration":0,"data":null,"wrap_info":null,"warnings":null,"auth":{"client_token":"s.ojvma4OkSZT7qKKRj7qYDswv","accessor":"K0pI3iNha8dUi3YCAxAzumRB","policies":["default","pmodemo"],"token_policies":["default","pmodemo"],"metadata":{"role":"pmodemo","service_account_name":"vault","service_account_namespace":"vault","service_account_secret_name":"","service_account_uid":"9218e2d0-56dd-48b6-b544-d136f79297a2"},"lease_duration":3600,"renewable":true,"entity_id":"05e3113e-7685-137a-c2c4-42fafcf5f71a","token_type":"service","orphan":true}

If a response similar to the above is displayed, Vault is installed and authentication is working. Now it is time to install and create an external secret! If you see an error, investigate the error appropriately. One of the most common errors is as follows:

- Error: connect EHOSTUNREACH = the vault endpoint env var in external secrets deployment is incorrect
- ERROR, namespace not authorized = the namespace is not set properly in the role
- ERROR, service account name not authorized = the service account is not proper in the role
- 403 permission denied = review your policy

External Secrets Deployment and Configuration**

Next, install and configure External Secrets:

oc project external-secrets
helm upgrade -i -n external-secrets external-secrets external-secrets/kubernetes-external-secrets --set "env.VAULT_ADDR=http://vault.vault.svc:8200"

The deployment of External Secrets relies on environment variables to configure where/how to reach the Vault API. This is set via the Helm value passed into the command above referencing the location of the Vault instance.

Let's now create the ExternalSecret manifest in a file called extsecret1.yml to reference the secret created in Vault previously. We will need to specify the vaultMountPoint and vaultRole properties to refer to the location of the secret within Vault.

apiVersion: kubernetes-client.io/v1
kind: ExternalSecret
metadata:
name: exsecret1
namespace: vault
spec:
backendType: vault
data:
- key: secret/data/vault-demo-secret1
name: password
property: password
vaultMountPoint: kubernetes
vaultRole: pmodemo
oc create -f extsecret1.yml

Check the Results

When we successfully create the ExternalSecret manifest, the External Secrets controller will create a Kubernetes Secret on the cluster containing the secret stored in Vault. So order of operations:

  1. ExternalSecret created
  2. Data pulled from Vault
  3. External Secret controller creates Kubernetes secret.

Only the Vault secret and the cluster secret should have the actual secret data. The ExternalSecret will contain just the reference.

oc get es -n vault

NAME LAST SYNC STATUS AGE
exsecret1 6s SUCCESS 22h

Finally, we can take a look at the secret that was created by the External Secrets controller as well as the data in the ExternalSecret. We see password data in the secret but not in the ExternalSecret, which allows us to store the ExternalSecret in Git without ever exposing the actual secret data.

oc -n vault get secrets exsecret1
NAME                          TYPE                                  DATA   AGE
exsecret1 Opaque 1 2m29s
oc -n vault get secret exsecret1 -o yaml
apiVersion: v1
data:
password: bm90dmVyeXNlY3VyZQ==
kind: Secret
….

You can view the decoded secret data and compare it to the secret you setup earlier:

oc -n vault extract secret/exsecret1 --to=-
# password
notverysecure

And we can once again verify that there is no sensitive data in the ExternalSecret manifest which would present a risk when committed to a git repository:

spec:
backendType: vault
data:
- key: secret/data/vault-demo-secret1
name: password
property: password
vaultMountPoint: kubernetes
vaultRole: pmodemo

It’s just that simple. In this demo, we setup an instance of Vault in "dev mode", enabled Kubernetes authentication, created a secret, a role and policy to manage access to the secret. We then created an ExternalSecret which holds the path to the sensitive data in Vault and allowed the controller to create the secret in OpenShift. One final reminder, in closing. Secrets are stored as an encoded value in etcd. To help protect secrets at rest, pursue encrypting etcd: https://docs.openshift.com/container-platform/4.7/security/encrypting-etcd.html.

Does CSS Support Single-line Comments?

Le Hollandais Volants -- Liens

En CSS, on ne peut pas utiliser les commentaires avec « // commentaire ».
Il n’y a que les « /* commentaire */ »

… à moins que… Si ?

En fait si, mais c’est un peu un hack et le « // » ne suffit pas.
Vous lirez l’article pour voir pourquoi, mais il faut faire ça, avec « // » au début et « {} » à la fin, sur la même ligne :

selecteur {
// ceci est un commentaire {}
width: 100%;
color: red;
}

(du coup, c’est pas du tout plus rapide que de faire /* commentaire */)


— (permalink)

Facebook est installé sur votre iPhone ? Désinstallez d'urgence l'application ! - Liens en vrac de sebsauvage

Le Hollandais Volants -- Liens

Un accéléromètre mesure les accélérations, donc les variations de vitesses (que ce soit en valeur numérique (passer 0 à 50 km/h par exemple) ou en direction (prendre un virage).
La vitesse, c’est la variation de la position en fonction du temps.

En fait mathématiquement, l’accélération est la dérivée de la vitesse, elle-même la dérivée de la position.

En connaissant une unique position à un instant T, et une unique vitesse (valeur + direction) à un instant T' (qui peut ou non être égale à l’instant T), alors on peut utiliser les mesures de l’accélération pour déterminer toute votre trajectoire.

Par exemple :
- je suis à Paris à minuit (position : à l’instant T) et ma vitesse est nulle (vitesse à l’instant T').
- on me met une cagoule sur la tête. Je détecte alors une accélération de 1g durant 2 seconde en direction du sud. Je sais que je me trouve alors à 2×9,8 m/s, soit 70 km/h.
- durant 8 heures, je ne sens plus rien, pas de changement d’accélération.
- enfin, je mesure une accélération de 2g durant 1 seconde vers le nord. Cette accélération est exactement opposée à l’accélération quand j’étais à Paris. Je sais alors que ma vitesse est de nouveau nulle.

Où me trouve-je ? Facile : j’ai fait 8 h à 70 km/h (donc 560 km) vers le sud en partant de Paris. Je suis donc aux alentour de Toulouse.

Avec un accéléromètre précis, qui mesure sur les tris axes (X, Y, Z) et sur les trois angles on peut capter les moindres changements de direction, et en déduit sa position.

Les systèmes embarqués dans les missiles, les fusées et les sous-marins utilisent ce genre de guidage, de façon autonome, sur 3 axes et avec 3 accéléromètres : calculant chaque changement de direction, d’accélération et la durée des différentes phases de déplacement, ils peuvent déterminer avec une grande précision où ils sont et où ils vont.

Si l’on n’a que la seule information de l’accélération durant X temps, on ne saura rien. Mais il suffit d’une seule coordonnée pour pouvoir tout retracer. Et ça, ça peut passer par le GPS, le réseau GSM, le réseau Wifi (les points d’accès ne varient pas), le capteur photo (coucou tel ou tel monument sur votre selfie, ou encore les données EXIF dans les photos !).

Ou encore, comme sur ton article : si deux téléphones captent les mêmes sons (ou les mêmes vibrations de l’accéléromètre) au même moment, il suffit de connaître la position d’un des téléphones pour savoir où était l’autre.
Et comme FB est installé à peu près partout, même si vous bloquez sa géolocalisation, vous pouvez être trahis par un parfait inconnu dans le métro ou dans bus, qui lui a laissé son GPS allumé…

Ça fait peur, mais visiblement, FB s’en sert.

Je vous laisse imaginer tous les autres, à commencer par Google (qui contrôle votre téléphone en entier, avec Android), et les fabricants des composants, qui ont tous des micro-OS dans les chipsets.

Entre ça et la détection du "bruit" dans les photos que vous prenez pour savoir quel appareil photo a pris quelle photo… ils sont complètement malades. De vrais génies oui, mais des malades quand-même.


— (permalink)

Facebook est installé sur votre iPhone ? Désinstallez d'urgence l'application !

Liens SebSauvage
« Apparement, Facebook se rabat sur l'accéléromètre lorsque l'utilisateur refuse de partager sa position. “Facebook lit les données de l'accéléromètre tout le temps. Si vous n'autorisez pas Facebook à accéder à votre position, l'application peut toujours déduire votre emplacement exact en vous regroupant avec des utilisateurs correspondant au même modèle de vibrations que celui enregistré par votre accéléromètre téléphonique”, expliquent les deux chercheurs. »

Les GAFAM: Tu les raccompagnes jusqu'à la porte, ils re-rentrent par la fenêtre.
Rappel: Les GAFAM s'en foutent de votre vie privée et de vos souhaits. Ils vivent de l'exploitation de votre vie privée. Cet article est un exemple supplémentaire.
(Et attendez que les documents récemment révélés sur Google décantent un peu, ça va être croustillant.)

EDIT: Complément: Oui, on peut utiliser l'accéléromètre pour deviner votre trajet: [PDF] https://dl.acm.org/doi/pdf/10.1145/3309074.3309076
(Permalink)

Malware found in npm package with millions of weekly downloads - The Record by Recorded Future

Liens SebSauvage
Quand ton système a des tonnes de dépendances, la faille d'une seule dépendance devient la faille de ton système. Multiplie les dépendances, tu multiplie les risques. Simple, mathématique.
C'est pour cela que malgré l'attrait du DRY et des jolies librairies qui font le café, je préfère réduire les dépendances tant que possible. Et pas seulement pour des raisons de sécurité, mais aussi de dette technique.
(Permalink)

BuildTheEarth.net

Liens SebSauvage
Ok c'est légèrement ambitieux: Ils veulent re-créer le monde en 1:1 dans Minecraft.
(Permalink)

New language features since Java 8 to 17 - Advanced Web Machinery

Liens SebSauvage
Java est loin d'être mon langage favorit, mais il faudrait que je me mette à jour.
(Permalink)

Flo

Blog Sohann | comments

Très instructif cet exposé : merci maîtresse !
Incroyable tout ce que ce petit bonhomme a réussi à intégrer en 4 mois!
Et bravo à tous les deux, pour cette organisation qui n’a pas dû être facile à mettre au point.
J’espère que vous arrivez, l’un et l’autre, à passer une nuit complète de temps en temps, sans avoir ce souci en tête , de ne pas oublier de se réveiller pour vérifier son taux…
Bisous à tous les 3
Tata Flo

Raspberry Pi 3 Fastboot - Less Than 2 Seconds - Bir Coder'ın Günlüğü

Liens SebSauvage
Booter un RasbpberryPi 3 en 2 secondes.
(Depuis l'allumage jusqu'à l'application Qt disponible, 2,82 secondes.)
(Note: sans support USB et réseau.)
(Permalink)

Edward Snowden : « Des gens mourront si vous affaiblissez le chiffrement », il estime que la vie privée est un pouvoir essentiel

Liens SebSauvage
(Permalink)

Tenacity

Le Hollandais Volants -- Liens

Un fork d'Audacity.


— (permalink)
more
mark as read