[{"content":" TRAVAILLEZ AVEC NOUS Nos services Architecture et intégration d’infrastructures Le besoin d’une infrastructure TI fiable, évolutive, disponible et sécuritaire n’a jamais été aussi essentiel au succès de votre organisation. Nous pouvons vous aider à optimiser vos investissements TI, à améliorer la performance, à atteindre vos objectifs de disponibilité et à éviter des problèmes coûteux. Infrastructure as Code et automatisation Nous possédons une vaste expérience de l’automatisation des déploiements d’infrastructures et d’applications à l’aide de divers outils, notamment Terraform, Ansible, Ansible Tower, VMware vRealize Automation/Orchestrator, des API, des outils personnalisés et du développement logiciel. De plus, nous sommes plutôt créatifs : nous trouverons aussi des façons d’intégrer vos systèmes existants. DevSecOps Intégrez la sécurité des applications et de l’infrastructure dès le départ, tout en maintenant des cycles de développement courts et fréquents. Nous pouvons vous aider à mettre en œuvre votre pratique DevSecOps et votre chaîne CI/CD afin d’atteindre votre vitesse de développement optimale. Observabilité Vos systèmes deviennent chaque jour plus complexes. Ils comportent de multiples couches et sont répartis sur plusieurs plateformes : matériel physique, machines virtuelles, conteneurs, JVM, microservices, API et files de messages. Nous savons comment mettre en place la surveillance, les alertes, la visualisation, le traçage, l’agrégation des journaux et les analyses nécessaires pour maximiser votre disponibilité. Conteneurisation Nous possédons une vaste expérience de l’automatisation des déploiements d’infrastructures et d’applications à l’aide de divers outils, notamment Terraform, Ansible, Ansible Tower, VMware vRealize Automation/Orchestrator, des API, des outils personnalisés et du développement logiciel. De plus, nous sommes plutôt créatifs : nous trouverons aussi des façons d’intégrer vos systèmes existants. Technologies de mégadonnées Que vos données soient au repos ou en mouvement, nous pouvons vous aider à mettre en place des infrastructures de mégadonnées modernes et sécurisées, sur site ou dans le nuage. Nous possédons de l’expérience avec les technologies suivantes : HortonWorks HDF/HDP (Ambari, NiFi, Kafka, Hadoop, Hive, Solr), Confluent Kafka, ainsi qu’avec des solutions connexes ou alternatives comme la pile Elastic (ELK) et MongoDB. À propos de nous Nous sommes expérimentés Depuis 1999, nous offrons des services-conseils au Canada et en France. Nous sommes pragmatiques Contrairement à d’autres, nous ne cherchons pas à vendre à nos clients des solutions complexes dont ils n’ont pas besoin. Nous sommes dévoués Nous livrons des solutions complètes, accompagnées d’une documentation détaillée et d’un transfert de connaissances rigoureux, conformément à vos normes. Nous joindre 2000, avenue McGill College, bureau 600\nMontréal (Québec) H3A 3H3, Canada Nous écrire ","date":"18 janvier 2021","externalUrl":null,"permalink":"/fr/","section":"","summary":"","title":"","type":"page"},{"content":"I recently undertook the migration of an on-premise Cloudera Kafka cluster to a Confluent Cloud dedicated cluster. I would like to share some of our experience on how we migrated Accounts and Permissions to Confluent Cloud. Even though they are both Kafka clusters, their implementation of access management is quite different and an as-is migration was impossible.\nBackground # Cloudera # Cloudera \u0026amp; Hortonworks Kafka distributions are typically configured with Kerberos as an authentication method, therefore a KDC needs to be supplied. Generally, the clusters are kerberized against a corporate directory such as Active Directory or RedHat IDM (FreeIPA), and thus rely on an external directory system to manage authentication. These corporate LDAP directories contain user account information and application accounts. Leveraging the corporate directory makes sense. as it is a great asset. Integrating with a corporate directory has a few, yet important advantages:\nAuthentication is fully managed and secured by Kerberos; Corporate policies such as password complexity and expiration have been implemented; The account provisioning process is usually supported by an established process and tool(s); Account lifecycle is usually well managed and taken care of. In the Cloudera Kafka distribution, authorization is taken care of by Apache Ranger. Typically, you would sync LDAP accounts and groups into Ranger via the Ranger usersync service, and then assign some authorization on services. Each Big Data service Ranger plug-in (e.g. HDFS, NiFi, Hive, Kafka) brings their own specific Access Control List (ACL) and implementation specifics. For example, in the case of Kafka Topic authorization, also called permissions in Ranger, we can configure them to allow or deny up to eight permissions:\nPublish; Consume; Configure; Describe; Create; Delete; Describe Configs; Alter Configs. It is best practice to implement a security model based on groups rather than individual accounts, it makes for a more flexible solution, and one that is also easier to maintain.\nI would like to point out that until Ranger v2.1.0 Consumer Group ACLs were not managed specifically in Ranger. Control of the authorization for a topic was managed at the topic level only, for instance by assigning the \u0026lsquo;Consume\u0026rsquo; permission.\nNote: Consumer Group ACLs need to be specifically managed in Confluent Cloud, or consumers of a topic will not be able to read from topics.\nConfluent Cloud # Accounts were substituted for API keys in Confluent Cloud. The API key/secret pair is generated either using the ccloud CLI or the Cloud Console. The API key and secret are generated locally in the control plane and cannot be modified after creation. There is no way to integrate back to an authentication system. Authentication and authorization is managed locally in Confluent Cloud.\nIntegration back to a corporate directory is not supported for topic security. This is quite different from the SSO/SAML integration supported for the Confluent Cloud UI or ccloud CLI. The UI, or the CLI are used for administrative tasks in your cloud instance only.\nIf API keys are not linked to a confluent service account with --service-account, the API keys are granted full access to all resources in the cluster. This is a nice feature when testing the platform, however when a multi-tenant cluster is implemented with users and various applications, security needs to be more granular.\nIf you need to restrict the scope of an API key, it will need to be attached to a service account on which ACLs can be applied. Confluent Cloud supports a subset of the Kafka ACL normally implemented with an on-premise implementation.\nThe supported Confluent Cloud Topic Kafka ACLs are:\nAlter; AlterConfigs; Create; Delete; Describe; DescribeConfigs; Read; Write. As you can notice, there are no \u0026lsquo;Consume\u0026rsquo; ACL just like in Ranger. As stated above, granular permissions have to be managed at the topic and consumer group level in order to authorize a consumer of a topic.\nSolution # We understand that Cloudera and Confluent Cloud Kafka provide very different authentication and authorization methods. However for customers that have invested in a multi-tenant security model based on LDAP groups; the implementation of a similar model with Confluent Cloud would makes sense if it were available. The solution would need to apply security automatically just like Ranger, it would also need to rely on LDAP groups to apply ACLs just like with Ranger. If these requirements were met, we can hope to minimize the migration efforts and risks since the \u0026ldquo;security rules\u0026rdquo; can be automatically applied to the new Confluent Cloud cluster as applications and users are migrated over to the cloud.\nWe decided to use Active Directory as the reference system to construct the tool that will be used to automate the account creation and authorization in Confluent. We will take full advantage of the current groups, accounts and membership relationship information that currently drives authorization in Cloudera Kafka and transpose it to the Confluent Cloud cluster. The goal is to fully automate the implementation of the current security model based on groups into Confluent Cloud and thus provide a smooth transition to the new platform. No manual adjustments should be necessary. It needs to be AD group driven only.\nThe glue, confluent_AD_sync.py was developed in Python. At every run, it will fetch AD relationships, pull in the Confluent configurations (service accounts, API Keys, ACL, clusters, environments), and determine what needs to be executed on a cluster so that Confluent Cloud stays in sync with the reference system being AD. Similar to Terraform, it can be executed in plan mode or in execution mode. At every run, it will analyze on how to go from the current state of the cluster to the desired state.\nIf users are added to \u0026ldquo;Kafka\u0026rdquo; groups in AD groups, on the next run, these users will be added to Confluent Cloud, and their topic ACL will be adjusted accordingly. If these users are removed from a given group, their ACL will be adjusted, and they will no longer be granted access to the topic(s). If any manual adjustments are performed in Confluent Cloud with the CLI (except for a few exclusion rules we have set), confluent_AD_sync.py will bring it back to the desired state by either adding or removing configurations within the cluster. Of course, any adjustments are first planned and then executed if desired. We have implemented fail-safes so that a human can verify the plan and execute it, if it is appropriate.\nThere are two type of execution plans, the first one is for user accounts, the second one is for application accounts. Their execution plan is handled very similarly, however, there are a few differences especially on the handling of the secret. These differences are described in the following sequence diagrams.\nDesign for User Access to a Cluster # %%{init: {'theme': 'base', 'themeVariables': { 'background': '#353a43', 'primaryColor': '#3498db', 'darkMode': true}}}%% sequenceDiagram autonumber participant User; participant Active Directory Provisioner; participant Active Directory; participant confluent_AD_sync; participant Confluent Control Plane; User-\u003e\u003eActive Directory Provisioner: Request a Role Active Directory Provisioner-\u003e\u003eActive Directory: Add member to group(s) activate confluent_AD_sync par Build Execution Plan confluent_AD_sync-\u003e\u003eActive Directory: Query Group Membership confluent_AD_sync-\u003e\u003eConfluent Control Plane: Get Environment / Get Cluster-ID confluent_AD_sync-\u003e\u003eConfluent Control Plane: Get Cluster Service-Accounts confluent_AD_sync-\u003e\u003eConfluent Control Plane: Get Cluster API Keys confluent_AD_sync-\u003e\u003eConfluent Control Plane: Get Cluster ACLs end deactivate confluent_AD_sync loop Creation: Execute for Every AD Member activate confluent_AD_sync alt User Account Does NOT exist confluent_AD_sync-\u003e\u003eConfluent Control Plane: Create Service-Account confluent_AD_sync-\u003e\u003eConfluent Control Plane: Adjust ACL based on AD group membership confluent_AD_sync-\u003e\u003eConfluent Control Plane: Create API-Key Confluent Control Plane--\u003e\u003eUser: Email API Key \u0026 Secret else Does Exist confluent_AD_sync-\u003e\u003eConfluent Control Plane: Adjust ACL based on AD group membership end deactivate confluent_AD_sync end loop Deletion: Execute for Every AD Member \u0026 ccloud account activate confluent_AD_sync alt User Found in ccloud but NOT in any AD Group confluent_AD_sync-\u003e\u003eConfluent Control Plane: Delete Service-Account confluent_AD_sync-\u003e\u003eConfluent Control Plane: Delete All ACLs confluent_AD_sync-\u003e\u003eConfluent Control Plane: Delete API-Key else User Found in ccloud but removed from some AD groups confluent_AD_sync-\u003e\u003eConfluent Control Plane: Delete ACL associated with group end deactivate confluent_AD_sync end With application accounts, there are a few differences on how the accounts are handled, most of the time, application accounts do not have a valid email account or an active email account, we therefore decided to dump the data directly into a vault. We see two benefits to this mechanism, first, the API Key and Secret are secured in a safe place for the application owner. Second, this enables and promotes the use of CI/CD pipelines in application deployments. The password can either be used directly by an application or handled by a pipeline. Typically the pipeline would copy the credentials in its own specific application vault.\nDesign for Application Accounts Access to a Cluster # %%{init: {'theme': 'base', 'themeVariables': { 'background': '#353a43', 'primaryColor': '#3498db', 'darkMode': true}}}%% sequenceDiagram autonumber participant Application Access Request; participant Active Directory Provisioner; participant Active Directory; participant confluent_AD_sync; participant Confluent Control Plane; participant Vault; participant CI/CD Pipeline; Application Access Request-\u003e\u003eActive Directory Provisioner: Request Application Account Active Directory Provisioner-\u003e\u003eActive Directory: Add member to group(s) activate confluent_AD_sync par Build Execution Plan confluent_AD_sync-\u003e\u003eActive Directory: Query Group Membership confluent_AD_sync-\u003e\u003eConfluent Control Plane: Get Environment / Get Cluster-ID confluent_AD_sync-\u003e\u003eConfluent Control Plane: Get Cluster Service-Accounts confluent_AD_sync-\u003e\u003eConfluent Control Plane: Get Cluster API Keys confluent_AD_sync-\u003e\u003eConfluent Control Plane: Get Cluster ACLs end deactivate confluent_AD_sync confluent_AD_sync-\u003e\u003econfluent_AD_sync: Generate Plan add/delete resources loop Creation: Execute for Application Account activate confluent_AD_sync alt Application Account Account Does NOT exist confluent_AD_sync-\u003e\u003eConfluent Control Plane: Create Service-Account confluent_AD_sync-\u003e\u003eConfluent Control Plane: Adjust ACL based on AD group membership confluent_AD_sync-\u003e\u003eConfluent Control Plane: Create API-Key Confluent Control Plane--\u003e\u003eVault: Put credentials in Vault else Does Exist confluent_AD_sync-\u003e\u003eConfluent Control Plane: Adjust ACL based on AD group membership end CI/CD Pipeline--\u003e\u003eVault: Get Credentials and Deploy Application deactivate confluent_AD_sync end Discussion on Relationships between AD and Confluent # In order to keep things simple, we maintain a one-to-one relationship between an AD account and a Confluent Cloud service account, the service account name is named after the AD sAMAccountName field in order to link back to the AD member. The service account name is limited to 32 characters.\nWe like to see and handle the service account a bit like a group, it regroups ACLs across clusters and contains a key to access these resources. Service Accounts are not specific to a cluster, but are common across environments (multiple clusters can be created in a given environment).\nsAMAccountName: applicationA Service_Account_Name: applicationA Even though it is possible to link multiple API keys to a single service account, we maintain a one-to-one relationship between a service account and an API key, this simplifies traceability and audit. Essentially a given user can only authenticate with a single account.\nActive Directory sAMAccountName: applicationA ccloud Service Account: Name: applicationA id: 123456 ccloud API-Key: key: \u0026lt;key\u0026gt; owner: 123456 description: \u0026#39;{ \u0026#34;name\u0026#34; : displayName, ... }\u0026#39; For traceability on the service accounts and API keys, we built a common JSON description that matches the user\u0026rsquo;s Active Directory information. This information is pushed into the description field of the service account or API key. This acts as meta data for further processing on service accounts and API keys. You are limited to 128 characters in the description field of the service account. As you can see below, we have 4 fields in the description, the displayName, the email, a timestamp, and a creator.\ndescription = json.dumps({ \\ \u0026#39;name\u0026#39;: ADDetails[member][\u0026#39;displayName\u0026#39;], \\ \u0026#39;mail\u0026#39;: ADDetails[member][\u0026#39;mail\u0026#39;], \\ \u0026#39;created\u0026#39;: whenCreated, \\ \u0026#39;creator\u0026#39;:\u0026#39;confluent-AD-sync\u0026#39;}) Relationship diagram between Active Directory Account and ccloud\n%%{init: {'theme': 'base', 'themeVariables': { 'background': '#353a43', 'primaryColor': '#3498db', 'darkMode': true}}}%% erDiagram AD-Account ||..|| ccloud-Service-Account : sAMAccountName ccloud-Service-Account ||--|| ccloud-API-Key : authenticate-with ccloud-Service-Account ||--|{ ccloud-ACL-Cluster1 : authorize-topics ccloud-Service-Account ||--|{ ccloud-ACL-Cluster2 : authorize-topics As the plan is built and executed, these relationships are enforced and maintained, any manual changes or deviations from the desired state are corrected to maintain these relationships.\nDiscussion on AD Groups # We have to understand that the current implementation of the security model provides access to topics based on Active Directory group membership. A given group membership provides access to a set of related topics.\nLet\u0026rsquo;s start the discussion with an example, for instance, if a user is a member of a group called DEV.HR.SALARY.READ the user will be granted READ access to topics with the PREFIX HR.SALARY.* within the Kafka DEV cluster. If this same user is removed from the DEV.HR.SALARY.READ group, his ACL will be revoked. If the user is removed from all Kafka groups, his service account, ACLs and API key will be deleted from the cluster.\nAs you can see, our group naming convention provides all the necessary information to enable automation. Let\u0026rsquo;s elaborate a little on the group naming convention, \u0026lt;environment\u0026gt;.\u0026lt;department\u0026gt;.\u0026lt;topic description=\u0026quot;\u0026quot;\u0026gt;.\u0026lt;acl\u0026gt;. The first field stands for the Kafka environment on which to apply the access to, the second field describes the department name, the third field describes the content of a topic and the last field describes our standardized ACL field, we have READ, READ WRITE or READ WRITE EXECUTE.\nIf you need to implement something similar, a descriptive group nomenclature helps in providing insight into what members should be granted.\nNow that we have a standardized naming convention for our groups, querying Active directory is quite straightforward, we just need to consider nested groups.\nRanger does not support nested groups; therefore, the security model had to be \u0026ldquo;flattened\u0026rdquo; in order to accommodate for this drawback. This is usually a hassle and a constraint for your Active Directory administrator. In order to provide flexibility with the model, we decided to implement the support for nesting.\nWhen querying for membership with the ldap module, you will want to handle nested groups, Microsoft provides a special string to add to the filter just for this. It will walk the chain of ancestry in objects all the way to the root until it finds a match. This can be a bit slow, but it is a known issue with this Microsoft LDAP feature. For faster queries but not integrated with Python, you can use PowerShell, it is quite fast.\nldap_memberof_filter = \u0026#39;memberOf:1.2.840.113556.1.4.1941:\u0026#39; ldap_user_obj_class = \u0026#39;user\u0026#39; ldap_group = \u0026#39;DEV.HR.SALARY.READ\u0026#39; ldap_member_filter = \u0026#34;(\u0026amp;(objectClass={})({}={}))\u0026#34;.format(ldap_user_obj_class, ldap_memberof_filter, ldap_group) If you want to implement this in Redhat IDM or FreeIPA, you will need to handle the nesting logic in Python so to walk the chain of groups until you find all the members. Circular references are not permitted in IDM, but I would advise to limit the depth of your queries.\nDiscussion on AD Accounts # In order to efficiently manage accounts in Confluent, a few LDAP attributes need to be pulled in. We\u0026rsquo;ve discussed the sAMAccountName field, this field is used as the service account name. The displayName attribute is used in the description field. Of course, the email address is used in the description field but also to communicate the user credentials.\nOne more field needs to be considered, that is UserAccountControl. This field contains the account property flags, for instance 0x202 describes a normal account, if the account is disabled, we need to add 0x002 (0x002 + 0x202 = 0x204 = 514 in decimal). This field is very important if you want to manage the account lifecycle. A good discussion on the UserAccountControl flags can be found here.\nConfluent Cloud Control Plane Interface # Now that we understand the Active Directory groups and the relationship with service accounts, API keys and ACLs, we need to interface with Confluent Control Plane in order to create and manage accounts. Unfortunately, as of this writing, there are no API available for the Control Plane. The only way to interface with the cloud platform is either through the CLI or the Web Interface.\nFortunately, the CLI is pretty straightforward and does support an output format of yaml or JSON. This makes the output easily parsable and transformed into a Python object.\ntry: stream = subprocess.check_output([\u0026#34;ccloud service-account list -o yaml\u0026#34;], shell=True) except subprocess.CalledProcessError as e: \u0026lt;handle the error\u0026gt; ... # output in yaml and converted to a list service_accounts = yaml.load(stream.read(), Loader=yaml.FullLoader) In our case, we simply created a set of functions that the plan will call upon in order to bring the cluster back into a desired state. We can create objects:\nCreate an api-key; Create a service account; Add a topic ACL; Add a group ACL; Add a cluster ACL. We can also delete objects:\nDelete a service account; Delete topic ACL; Delete group ACL; Delete a cluster ACL. The plan will always compile what needs to be executed first and then execute de code against the control plane in the right order.\nBelow is a sample of some of the CLI commands that needs to be run in order to create the confluent objects. This is just a sample output of how everything is knit together with the CLI.\n## Create the Service Account based on AD (Service accounts are valid accross Kafka clusters in a given environment) ccloud service-account create \u0026lt;sAMAccountName\u0026gt; --description \u0026#34;\u0026lt;json description\u0026gt;\u0026#34; -o yaml id: \u0026lt;id\u0026gt; name: \u0026lt;sAMAccountName\u0026gt; ## Grant Access based on group ownership (ACLs are valid across Kafka clusters in a given environment) ccloud kafka acl create --allow --service-account \u0026lt;id\u0026gt; --operation \u0026#34;READ\u0026#34; --topic \u0026lt;topic prefix\u0026gt; --prefix ## Create the api-key (Valid for one cluster only) ccloud api-key create --service-account \u0026lt;id\u0026gt; --resource \u0026lt;cluster ID\u0026gt; --description \u0026#34;\u0026lt;json description\u0026gt;\u0026#34; -o yaml key: \u0026lt;key\u0026gt; secret: \u0026lt;long secret\u0026gt; Considered Alternatives and Final Thoughts # For the authorization portion of things, an alternative to confluent-AD-sync.py could have been the development of a Ranger integration with Confluent Cloud. The native Ranger usersync service would have taken care of syncing the proper Kafka groups from Active Directory; the UI interface would have allowed for a granular and flexible authorization assignments. The only piece missing would have been the interface with Confluent Cloud.\nSimply put, this could have been developed by parsing and understanding the Ranger policy cache found in /etc/ranger/\u0026lt;cluster_name\u0026gt;/policycache/kafka_\u0026lt;cluster_name\u0026gt;.json or by the use of the Ranger API. From this authoritative JSON source, we would be able reconstruct the group membership and its relationship to topics, and apply or delete the corresponding ACLs.\nOf course, the account provisioning process would still have to be taken care of somehow.\nConclusion # We understand that maintaining the source of truth in Active Directory has advantages. AD is usually at the core of the enterprise, and mature processes are in place for identity and access management. We feel that anytime we can lean on a reference system, it\u0026rsquo;s a plus within the organization.\nconfluent-AD-sync.py takes advantage of LDAP as a source system and ensures that Confluent Cloud is kept in sync with the account provisioning and authorization. Of course, there are drawbacks to such an implementation, but the automation and consistency it provides greatly outweighs the disadvantages of this integration.\n","date":"18 janvier 2021","externalUrl":null,"permalink":"/fr/posts/am-cloudera-kafka-to-confluent/","section":"Blog","summary":"I recently undertook the migration of an on-premise Cloudera Kafka cluster to a Confluent Cloud dedicated cluster. I would like to share some of our experience on how we migrated Accounts and Permissions to Confluent Cloud. Even though they are both Kafka clusters, their implementation of access management is quite different and an as-is migration was impossible.","title":"Access Management: Cloudera Kafka to Confluent Cloud Kafka Migration","type":"posts"},{"content":"","date":"18 janvier 2021","externalUrl":null,"permalink":"/fr/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","date":"18 janvier 2021","externalUrl":null,"permalink":"/fr/posts/","section":"Blog","summary":"","title":"Blog","type":"posts"},{"content":"","date":"18 janvier 2021","externalUrl":null,"permalink":"/fr/categories/","section":"Catégories","summary":"","title":"Catégories","type":"categories"},{"content":"","date":"18 janvier 2021","externalUrl":null,"permalink":"/fr/tags/ccloud/","section":"Tags","summary":"","title":"Ccloud","type":"tags"},{"content":"","date":"18 janvier 2021","externalUrl":null,"permalink":"/fr/tags/cloudera/","section":"Tags","summary":"","title":"Cloudera","type":"tags"},{"content":"","date":"18 janvier 2021","externalUrl":null,"permalink":"/fr/categories/coding/","section":"Catégories","summary":"","title":"Développement","type":"categories"},{"content":"","date":"18 janvier 2021","externalUrl":null,"permalink":"/fr/categories/bigdata/","section":"Catégories","summary":"","title":"Données massives","type":"categories"},{"content":"","date":"18 janvier 2021","externalUrl":null,"permalink":"/fr/tags/hortonworks/","section":"Tags","summary":"","title":"Hortonworks","type":"tags"},{"content":"","date":"18 janvier 2021","externalUrl":null,"permalink":"/fr/authors/jason/","section":"Authors","summary":"","title":"Jason","type":"authors"},{"content":"","date":"18 janvier 2021","externalUrl":null,"permalink":"/fr/tags/kafka/","section":"Tags","summary":"","title":"Kafka","type":"tags"},{"content":"","date":"18 janvier 2021","externalUrl":null,"permalink":"/fr/tags/python/","section":"Tags","summary":"","title":"Python","type":"tags"},{"content":"","date":"18 janvier 2021","externalUrl":null,"permalink":"/fr/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"2 octobre 2019","externalUrl":null,"permalink":"/fr/categories/news/","section":"Catégories","summary":"","title":"Actualités","type":"categories"},{"content":"","date":"2 octobre 2019","externalUrl":null,"permalink":"/fr/authors/marco/","section":"Authors","summary":"","title":"Marco","type":"authors"},{"content":" C’est officiel : nous avons maintenant plus de 20 ans ! # En septembre 1999, Jason Livie, Marco Ponton, Martin Bertrand et Philippe Tremblay ont créé Quadra Knowledge, une équipe de consultants UNIX hautement qualifiés. (Au fait, si vous ne le saviez pas, « Quadra » vient des \u0026ldquo;quatre\u0026rdquo; fondateurs.) À l’époque, nous étions essentiellement dédiés à l’écosystème IBM. Nos compétences de pointe sur AIX faisaient de nous un partenaire idéal pour IBM pSeries appelé à participer à la mise en œuvre de solutions robustes et de grande envergure auprès de clients au Canada et en France.\nAu fil des ans, le secteur s’est de plus en plus tourné vers les technologies ouvertes, et nous avons adapté notre offre de services en conséquence. Aujourd’hui, même si AIX nous rappelle parfois de bons souvenirs, nous sommes de grands adeptes des logiciels libres et la majeure partie de notre travail se fait sous Linux. Malheureusement, notre site Web ne le reflétait pas. Très occupés à aider nos clients, nous l’avons négligé pendant longtemps. Pour souligner nos 20 ans, nous avons donc décidé de le rafraîchir afin de proposer un contenu à jour et de nous assurer que personne n’ait l’impression d’avoir voyagé dans le temps en le visitant.\nAu cours de ce qui pourrait représenter plusieurs vies dans le monde des TI, de nombreuses technologies emballantes ont transformé notre façon de travailler. Nous avons hâte de voir ce que nous réservent les 20 prochaines années.\nSanté !\nL’équipe QK\n","date":"2 octobre 2019","externalUrl":null,"permalink":"/fr/posts/we-are-20/","section":"Blog","summary":"En septembre 1999, Jason Livie, Marco Ponton, Martin Bertrand et Philippe Tremblay ont créé Quadra Knowledge, une équipe de consultants UNIX hautement qualifiés. (Au fait, si vous ne le saviez pas, « Quadra » vient des “quatre” fondateurs.) À l’époque, nous étions essentiellement dédiés à l’écosystème IBM. Nos compétences de pointe en AIX faisaient de nous un partenaire idéal pour IBM pSeries appelé à participer à la mise en œuvre de solutions robustes et de grande envergure auprès de clients au Canada et en France.","title":"Nous avons 20 ans !","type":"posts"},{"content":" Colors # Autumn # Avocado # Bloody # Blowfish # Burufugu # Congo # Fire # Forest # GitHub # Marvel # Neon # Noir # Ocean # One Light # Princess # Slate # Terminal # ","externalUrl":null,"permalink":"/colors/","section":"","summary":"","title":"","type":"page"},{"content":"","externalUrl":null,"permalink":"/fr/series/","section":"Series","summary":"","title":"Series","type":"series"}]