GitKraken, the world’s leader in creating premier Git tools for software developers, will host the 2nd annual GitKon tech conference 11-13 October 2022. This free, virtual event will bring together developers, technical teams, managers, executives, and thought leaders united by a passion for software development, team collaboration, and Git.
The event will offer 36 sessions across three days of content with speakers from companies like GitHub, GitLab, Microsoft and VS Code, Atlassian, Amazon, and more. Each day, 12 tech experts will have 15 minutes to present their thoughts on topics ranging from DevOps, distributed collaboration, security, developer skills, emerging trends, and more.
Registration for GitKon is completely free on gitkon.com.
One of the most anticipated sessions of this year’s event is the keynote presentation on Tuesday, 11 October. Drupal Founder and Acquia CTO/Co-Founder, Dries Buytaert will present: From the Dorm Room to The White House – How Drupal Grew and Became the Standard for Open Source Web Experiences.
In this talk, Dries will tell the Drupal story, including how the team was able to achieve success ultimately by embracing open source.
Bringing people together under a shared passion is at the heart of what Drupal does,” says Dries. “GitKon is a great venue for sharing our story, and I’m excited to pass along lessons learned to show more teams that they can also achieve corporate success by supporting open source.
Founded in 2001, Drupal is a free and open source web content management system that has scaled to become a standard tool in the industry. While Dries initially created Drupal as a simple message board that could be easily edited and managed by his college community, the tool quickly gained popularity with developers and currently powers millions of websites worldwide.
GitKraken CEO, Matt Johnston is a former colleague of Dries, joining his team after Acquia acquired Mautic, an open source marketing automation leader for which Johnston served as the CEO before joining GitKraken.
I’ve known Dries for a decade and had the pleasure of working directly with him on Acquia’s Marketing Cloud solutions,” says Matt. “His ability to balance the needs of Drupal and Acquia–while simultaneously scaling both–is a rare feat. Dries’ talk will be an awesome opportunity for GitKon attendees to hear about open source innovation.
The theme of GitKon 2022 is Creating a Collaborative Future, a mission at the heart of what Drupal does and stands for, with collaboration through the open source community leading Drupal’s success and now Acquia’s mission.
To hear Dries and other tech experts from around the world, register now for free at gitkon.com.
Secrets contain sensitive information, but they aren’t encrypted by default. Learn how to encrypt an etcd database to manage vital information in OpenShift. Read More at Enable Sysadmin
The post How to encrypt etcd and use secrets in OpenShift appeared first on Linux.com.
To protect web resources with Kerberos you may use Apache HTTPD with mod_auth_gssapi — however, all web scripts (e.g., PHP) run under Apache will have access to the Kerberos long-term symmetric secret credential (keytab). If someone can get it, they can impersonate your server, which is bad.
The gssproxy project makes it possible to introduce privilege separation to reduce the attack surface. There is a tutorial for RPM-based distributions (Fedora, RHEL, AlmaLinux, etc), but I wanted to get this to work on a DPKG-based distribution (Debian, Ubuntu, Trisquel, PureOS, etc) and found it worthwhile to document the process. I’m using Ubuntu 22.04 below, but have tested it on Debian 11 as well. I have adopted the gssproxy package in Debian, and testing this setup is part of the scripted autopkgtest/debci regression testing.
First install the required packages:
root@foo:~# apt-get update
root@foo:~# apt-get install -y apache2 libapache2-mod-auth-gssapi gssproxy curlThis should give you a working and running web server. Verify it is operational under the proper hostname, I’ll use foo.sjd.se in this writeup.
root@foo:~# curl --head http://foo.sjd.se/
HTTP/1.1 200 OK
…The next step is to create a keytab containing the Kerberos V5 secrets for your host, the exact steps depends on your environment (usually kadmin ktadd or ipa-getkeytab), but use the string “HTTP/foo.sjd.se” and then confirm using something like the following.
root@foo:~# ls -la /etc/gssproxy/httpd.keytab
-rw------- 1 root root 176 Sep 18 06:44 /etc/gssproxy/httpd.keytab
root@foo:~# klist -k /etc/gssproxy/httpd.keytab -e
Keytab name: FILE:/etc/gssproxy/httpd.keytab
KVNO Principal
---- --------------------------------------------------------------------------
2 HTTP/foo.sjd.se@GSSPROXY.EXAMPLE.ORG (aes256-cts-hmac-sha1-96)
2 HTTP/foo.sjd.se@GSSPROXY.EXAMPLE.ORG (aes128-cts-hmac-sha1-96)
root@foo:~# The file should be owned by root and not be in the default /etc/krb5.keytab location, so Apache’s libapache2-mod-auth-gssapi will have to use gssproxy to use it.
Then configure gssproxy to find the credential and use it with Apache.
root@foo:~# cat<<EOF > /etc/gssproxy/80-httpd.conf
[service/HTTP]
mechs = krb5
cred_store = keytab:/etc/gssproxy/httpd.keytab
cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_%U
euid = www-data
process = /usr/sbin/apache2
EOFFor debugging, it may be useful to enable more gssproxy logging:
root@foo:~# cat<<EOF > /etc/gssproxy/gssproxy.conf
[gssproxy]
debug_level = 1
EOF
root@foo:~#Restart gssproxy so it finds the new configuration, and monitor syslog as follows:
root@foo:~# tail -F /var/log/syslog &
root@foo:~# systemctl restart gssproxyYou should see something like this in the log file:
Sep 18 07:03:15 foo gssproxy[4076]: [2022/09/18 05:03:15]: Exiting after receiving a signal
Sep 18 07:03:15 foo systemd[1]: Stopping GSSAPI Proxy Daemon…
Sep 18 07:03:15 foo systemd[1]: gssproxy.service: Deactivated successfully.
Sep 18 07:03:15 foo systemd[1]: Stopped GSSAPI Proxy Daemon.
Sep 18 07:03:15 foo gssproxy[4092]: [2022/09/18 05:03:15]: Debug Enabled (level: 1)
Sep 18 07:03:15 foo systemd[1]: Starting GSSAPI Proxy Daemon…
Sep 18 07:03:15 foo gssproxy[4093]: [2022/09/18 05:03:15]: Kernel doesn't support GSS-Proxy (can't open /proc/net/rpc/use-gss-proxy: 2 (No such file or directory))
Sep 18 07:03:15 foo gssproxy[4093]: [2022/09/18 05:03:15]: Problem with kernel communication! NFS server will not work
Sep 18 07:03:15 foo systemd[1]: Started GSSAPI Proxy Daemon.
Sep 18 07:03:15 foo gssproxy[4093]: [2022/09/18 05:03:15]: Initialization complete.
The NFS-related errors is due to a default gssproxy configuration file, it is harmless and if you don’t use NFS with GSS-API you can silence it like this:
root@foo:~# rm /etc/gssproxy/24-nfs-server.conf
root@foo:~# systemctl try-reload-or-restart gssproxyThe log should now indicate that it loaded the keytab:
Sep 18 07:18:59 foo systemd[1]: Reloading GSSAPI Proxy Daemon…
Sep 18 07:18:59 foo gssproxy[4182]: [2022/09/18 05:18:59]: Received SIGHUP; re-reading config.
Sep 18 07:18:59 foo gssproxy[4182]: [2022/09/18 05:18:59]: Service: HTTP, Keytab: /etc/gssproxy/httpd.keytab, Enctype: 18
Sep 18 07:18:59 foo gssproxy[4182]: [2022/09/18 05:18:59]: New config loaded successfully.
Sep 18 07:18:59 foo systemd[1]: Reloaded GSSAPI Proxy Daemon.
To instruct Apache — or actually, the MIT Kerberos V5 GSS-API library used by mod_auth_gssap loaded by Apache — to use gssproxy instead of using /etc/krb5.keytab as usual, Apache needs to be started in an environment that has GSS_USE_PROXY=1 set. The background is covered by the gssproxy-mech(8) man page and explained by the gssproxy README.
When systemd is used the following can be used to set the environment variable, note the final command to reload systemd.
root@foo:~# mkdir -p /etc/systemd/system/apache2.service.d
root@foo:~# cat<<EOF > /etc/systemd/system/apache2.service.d/gssproxy.conf
[Service]
Environment=GSS_USE_PROXY=1
EOF
root@foo:~# systemctl daemon-reloadThe next step is to configure a GSS-API protected Apache resource:
root@foo:~# cat<<EOF > /etc/apache2/conf-available/private.conf
<Location /private>
AuthType GSSAPI
AuthName "GSSAPI Login"
Require valid-user
</Location>Enable the configuration and restart Apache — the suggested use of reload is not sufficient, because then it won’t be restarted with the newly introduced GSS_USE_PROXY variable. This just applies to the first time, after the first restart you may use reload again.
root@foo:~# a2enconf private
Enabling conf private.
To activate the new configuration, you need to run:
systemctl reload apache2
root@foo:~# systemctl restart apache2
When you have debug messages enabled, the log may look like this:
Sep 18 07:32:23 foo systemd[1]: Stopping The Apache HTTP Server…
Sep 18 07:32:23 foo gssproxy[4182]: [2022/09/18 05:32:23]: Client [2022/09/18 05:32:23]: (/usr/sbin/apache2) [2022/09/18 05:32:23]: connected (fd = 10)[2022/09/18 05:32:23]: (pid = 4651) (uid = 0) (gid = 0)[2022/09/18 05:32:23]:
Sep 18 07:32:23 foo gssproxy[4182]: message repeated 4 times: [ [2022/09/18 05:32:23]: Client [2022/09/18 05:32:23]: (/usr/sbin/apache2) [2022/09/18 05:32:23]: connected (fd = 10)[2022/09/18 05:32:23]: (pid = 4651) (uid = 0) (gid = 0)[2022/09/18 05:32:23]:]
Sep 18 07:32:23 foo systemd[1]: apache2.service: Deactivated successfully.
Sep 18 07:32:23 foo systemd[1]: Stopped The Apache HTTP Server.
Sep 18 07:32:23 foo systemd[1]: Starting The Apache HTTP Server…
Sep 18 07:32:23 foo gssproxy[4182]: [2022/09/18 05:32:23]: Client [2022/09/18 05:32:23]: (/usr/sbin/apache2) [2022/09/18 05:32:23]: connected (fd = 10)[2022/09/18 05:32:23]: (pid = 4657) (uid = 0) (gid = 0)[2022/09/18 05:32:23]:
root@foo:~# Sep 18 07:32:23 foo gssproxy[4182]: message repeated 8 times: [ [2022/09/18 05:32:23]: Client [2022/09/18 05:32:23]: (/usr/sbin/apache2) [2022/09/18 05:32:23]: connected (fd = 10)[2022/09/18 05:32:23]: (pid = 4657) (uid = 0) (gid = 0)[2022/09/18 05:32:23]:]
Sep 18 07:32:23 foo systemd[1]: Started The Apache HTTP Server.
Finally, set up a dummy test page on the server:
root@foo:~# echo OK > /var/www/html/privateTo verify that the server is working properly you may acquire tickets locally and then use curl to retrieve the GSS-API protected resource. The "--negotiate" enables SPNEGO and "--user :" asks curl to use username from the environment.
root@foo:~# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: jas@GSSPROXY.EXAMPLE.ORG
Valid starting Expires Service principal
09/18/22 07:40:37 09/19/22 07:40:37 krbtgt/GSSPROXY.EXAMPLE.ORG@GSSPROXY.EXAMPLE.ORG
root@foo:~# curl --negotiate --user : http://foo.sjd.se/private
OK
root@foo:~#The log should contain something like this:
Sep 18 07:56:00 foo gssproxy[4872]: [2022/09/18 05:56:00]: Client [2022/09/18 05:56:00]: (/usr/sbin/apache2) [2022/09/18 05:56:00]: connected (fd = 10)[2022/09/18 05:56:00]: (pid = 5042) (uid = 33) (gid = 33)[2022/09/18 05:56:00]:
Sep 18 07:56:00 foo gssproxy[4872]: [CID 10][2022/09/18 05:56:00]: gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service "HTTP", euid: 33,socket: (null)
Sep 18 07:56:00 foo gssproxy[4872]: [CID 10][2022/09/18 05:56:00]: gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service "HTTP", euid: 33,socket: (null)
Sep 18 07:56:00 foo gssproxy[4872]: [CID 10][2022/09/18 05:56:00]: gp_rpc_execute: executing 1 (GSSX_INDICATE_MECHS) for service "HTTP", euid: 33,socket: (null)
Sep 18 07:56:00 foo gssproxy[4872]: [CID 10][2022/09/18 05:56:00]: gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service "HTTP", euid: 33,socket: (null)
Sep 18 07:56:00 foo gssproxy[4872]: [CID 10][2022/09/18 05:56:00]: gp_rpc_execute: executing 9 (GSSX_ACCEPT_SEC_CONTEXT) for service "HTTP", euid: 33,socket: (null)
The Apache log will look like this, notice the authenticated username shown.
127.0.0.1 - jas@GSSPROXY.EXAMPLE.ORG [18/Sep/2022:07:56:00 +0200] "GET /private HTTP/1.1" 200 481 "-" "curl/7.81.0"
Congratulations, and happy hacking!
In 2020, we announced we were in the early phases of establishing the Chrome Root Program and launching the Chrome Root Store.
The Chrome Root Program ultimately determines which website certificates are trusted by default in Chrome, and enables more consistent and reliable website certificate validation across platforms.
This post shares an update on our progress and how these changes help us better protect Chrome’s users.
Chrome uses digital certificates (often referred to as “certificates,” “HTTPS certificates,” or “server authentication certificates”) to ensure the connections it makes on behalf of its users are secure and private. Certificates are responsible for binding a domain name to a public key, which Chrome uses to encrypt data sent to and from the corresponding website.
As part of establishing a secure connection to a website, Chrome verifies that a recognized entity known as a “Certification Authority” (CA) issued its certificate. Certificates issued by a CA not recognized by Chrome or a user’s local settings can cause users to see warnings and error pages.
Root stores, sometimes called “trust stores”, tell operating systems and applications what certification authorities to trust. The Chrome Root Store contains the set of root CA certificates Chrome trusts by default.
A root program is a governance structure that establishes the requirements and security review functions needed to manage the corresponding root store. Members of the Chrome Security Team are responsible for the Chrome Root Program. Our program policy, which establishes the minimum requirements for CAs to be included in the Chrome Root Store, is publicly available here.
Historically, Chrome integrated with the root store and certificate verification process provided by the platform on which it was running. Standardizing the set of CAs trusted by Chrome across platforms through the transition to the Chrome Root Store, coupled with a consistent certificate verification experience through the use of the Chrome Certificate Verifier, will result in more consistent user and developer experiences.
Launching the Chrome Root Program also represents our ongoing commitment to participating in and improving the Web PKI ecosystem. Innovations like ACME have made it easier than ever for website owners to obtain HTTPS certificates. Technologies like Certificate Transparency promote increased accountability and transparency, further improving security for Chrome’s users. These enhancements, only made possible through community collaboration, make the web a safer place. However, there’s still more work to be done.
We want to work alongside CA owners to define and operationalize the next generation of the Web PKI. Our vision for the future includes modern, reliable, highly agile, purpose-driven PKIs that promote automation, simplicity, and security – and we formed the Chrome Root Program and corresponding policy to achieve these goals.
A “rollout” is a gradual launch of a new feature. Sometimes, to ensure it goes smoothly, we don’t enable a new feature for all of our users at once. Instead, we start with a small percentage of users and increase that percentage over time to ensure we minimize unanticipated compatibility issues. The Chrome Root Store and Certificate Verifier began rolling out on Windows and macOS in Chrome 105, with other platforms to follow.
We expect the transition to the Chrome Root Store and Certificate Verifier to be seamless for most users, enterprises, and CA owners.
The Chrome Certificate Verifier considers locally-managed certificates during the certificate verification process. This means if an enterprise distributes a root CA certificate as trusted to its users (for example, by a Windows Group Policy Object), it will be considered trusted in Chrome.
Troubleshooting procedures and other frequently asked questions are available here.
While we don’t know exactly what the future of the Web PKI will look like, we remain focused on promoting changes that increase speed, security, stability, and simplicity throughout the ecosystem.
With that in mind, the Chrome team continues to explore introducing future root program policy requirements related to the following initiatives:
Encouraging modern infrastructures and agility
Focusing on simplicity
Promoting automation
Reducing mis-issuance
Increasing accountability and ecosystem integrity
Streamlining and improving domain validation practices
Preparing for a “post-quantum” world
We look forward to continuing our collaboration with members of the CA/Browser Forum and other Web PKI ecosystem participants to make the Internet a safer place.